Posts by thebajaguy

Or read the OS 3.2.2 documentation, and install the minimal MuLibs package after the OS install.

There's an 'Amiga Network Boot Disk' that someone put together with AmiTCP 3.0 to be found with some creative searching. The thin client boot mentioned is one reason for it (with customization). The other reason is for a way to do a clean-backup, and clean-restore of a system from that backup, maybe it's a base image. The trick is that AmiTCP 3.0 always needs to be set up with a Static IP. Once the setup is deemed functional, one can take a copy of that boot disk, remove the reconfiguration scripting and unneeded card drivers, and add anything back that is desired/needed before a network link were to come up.

Based on the above thread comments, AmiTCP4 should be able to do the same. It takes digging in to what bare components (files) are needed, and what configuration files are set to - a learning experience. Any tool in the IP stack not needed to connect is on a folder on the network that is added to the search path (after connecting) vs taking up space on the floppy.

I also did this kind of thing back in the mid-90's to effect a (then) Win 3.11/DOS 6.22 image copy-down using a TCP/IP boot floppy. In the (then) pre-Ghost days, it was much faster, and near-seamless to configure the host, than waiting on and maintaining a stack of floppy disks. I have one of these network boot disks as an ADF for my Amiga PLIP boxes when I need to backup/image someone's system before wiping and reloading.

For atrain01us - The ShowConfig tool in the more recent Amiga OS releases can use boards.library. Older releases can get/use this:

http://m68k.aminet.net/package/util/libs/BoardsLib

You can also dig up some info here: https://wiki.amigaos.net/wiki/…_Manufacturer_ID_Registry

Thanks for the speculation. An item possibly for Dave to consider at some point, or at least offer an opinion - if he chooses.

Quote from Jens

Buster controls bus timing for all the different cases of "data source" vs. "data destination".

I realize this is kind of tangent...among the curiosity of that explanation, I know that the TekMagic/GVP T-Rex II 68060, with it's 53C710, doesn't like the A4000T's 53C710 being there. The same basic card, the Ultrasound version, without the SCSI interface, runs without issue. I'm curious if any other A4000D-targeted accelerators with SCSI on them have a similar conflict in the A4000T? and if Buster would have any say in the matter?

I agree that Dave did a very good job considering the (lack of) resources available.

Most of my understanding of the Buster chip behavior is from Dave Haynie's notes from back in the day:

http://wonkity.com/~wblock/a4000hard/defibust.html

The -09 seems to be okay for Z2, and unrelated forum posts I recall since have implied the -09 might even be better fit than -11 for the 16MHz A3000D models in some cases,. but Dave's notes imply fixes included in -11 for the A4000-series related to Z3 expansion bus.

From personal reading of the forums over the years, the use of an accelerator on any machine can muddy the waters. Each design, being different, can load some unbuffered bus signals in different ways, and affect Buster, Gary, or other chips' timing slightly. The lack of resources Dave noted back in the day made for some uncertainties which could not be well tested, and the too-old adage 'YMMV' has to be applied.

Nevertheless, I am also interested in a -12 (or whatever it's deemed) if/when it can be produced.

One thing I am interested in (at some point) is to understand where Buster comes into play when there is a 57C710 on the motherboard (i.e. - A4000T), and/or there is a similar/identical 53C7xx chip on a CPU slot accelerator (P5, TekMagic, a few others?) in the A4000D/T - what part does Buster play in managing or cooperating with this additional busmaster on the CPU-side?

I don't know if it's an applicable solution, but the GVP G-Force 040's FastROM, or the GuruROM, driver places a 'dummy' Autoconfig board into the system board list (when it detects that card) for it's onboard I/O extender which sits at a different offset on the AutoConfig PIC. Later, when the I/O extender driver gets loaded from a Binddrivers call, it will find that card, as well as any legitimate Z2 I/O Extender cards, and the driver mates to them.

Maybe this has some possible ideas to work with?

My comment regarding Buster is related to a project mentioned prior to the pandemic/chip shortages for certain CPLDs/FPGAs on the market. A certain famous engineer of the Amiga Buster chip was looking into possibly redesigning something new/replacement for Buster - and finish the work that couldn't be finished due to C='s financial state back in the early 1990's. It's all on hold, though, until a viable supply of parts can be secured, and also fully redeveloped and tested. With reprogrammable parts, though, the high cost of classic chip-fab is no longer there. I'd say there's a decent market for an improved Buster if one might get produced.

As for the ZIP sockets coming out, that would be a bit of slow and steady work. I might suggest a lighted magnifying glass on an arm. I also invested in a desoldering unit, but I still use the manual suction tube method. You will want to add modern solder to each pin before you vacuum it out. The solder you use today and what they used for wave soldering back in the day has slightly different properties. It's easier if you add a little before extracting.

If you have a RAMSEY-07 in the A3000T, then it's paired with the unobtanium chip known as SDMAC-04, which is an ideal combo. Look for the Dave Haynie notes on the Buster/SDMAC - they are online. Alas, if you have the A3000D with the RAMSEY-04, it needs to be paired with the SDMAC-02. It's generally fine for stock systems. It can have some issues with some accelerators' load on some signals, and you would want a Buster-11 if you have any Z-3 cards.

On my one A3000D, it had a hacked ZIP-2-SIMM solution with tons of ~4" wires to offset it for accelerator use - from the past owner.

I chose to remove it all, and put the (albeit different memory solution) 16MB ZIP-2-DRAM board (a limited run AmiBay offering) directly on the motherboard where the ZIP sockets are. It's flush with the motherboard. and very neat, allowing much more airflow through the region. I still have that crazy ZIP-2-SIMM board with all the wires... in a box.

I'd suggest you go with the ZIP-2-SIMM board directly to the motherboard. If you are worried about clearance, make sure you trim all the pins on the ZIP-2-SIMM back side, and a thin clear plastic separator similar to what is under the motherboard next to the shield. That would let you not use the plastic separator common to most header strips. You might get away with just using the longer side of a pin strip header.

And as for the BigRAM+, it's a reasonable solution when there is no other option, but it's also on the other side of Buster, and well, we still need a better Buster before the BigRAM could perform as well as CPU-side RAMSEY memory. We keep hoping that project might one day continue to happen.

Scenario: If I was using the GVP with only a SCSI CD-ROM, the boot time ROM is a boot-delayer as it has to time out every time I boot up (never finding a HD). This isn't your issue, but the workaround is how classic expansion slot controllers would also address a CDROM-only configuration.

To solve this, I'd disable the ROM on the card, and during boot (from some other device), have the gvpscsi (+icon) driver in SYS:Expansion from the GVP floppy on the booting media (i.e. - a different HD controller, like on the A3000). When the startup-sequence encounters Binddrivers, it looks in SYS:expansion, loads that driver (needs the icon) and that driver activates the GVP controller, scanning and finding the CDROM on the bus after polling.

Shortly after, with other commands called (this is a generic statement), the media mounting for the CD can happen. In older OS, one would use a Mountlist entry for the CD rive, and call Mount command during s:user-startup. In newer OS 3.1.4 and later, you would have a DOSDriver that contains essentially the same information as a DEVS:Mountlist file entry, and the Storage/DOSDrivers folder already has a pre-made example for CDROMs. The information for the controller card driver would need to be edited at minimum, and possibly an adjustment for the unit ID on the controller. (SCS uses a value from =0-6, IDE uses either 0 or 1).

I don't know if the Buddah has that same driver option for use in SYS:Expansion option - my experience with it is limited. I believe it has a ROM onboard which is always? active, and should not require the Binddrivers/Sys:Expansion driver method. My own Buddah card is packed away for a few weeks as I shuffle my tech room around in my apartment and I am also on the road for work. In theory, the 2 cards should work together without issue.

Please also note the slot order of both cards (and any others), and if swapping their order makes any difference. Lowest slot is to the right, and highest slot is to the left in an (assumed) A2000 expansion bus.

Shop link at the top (open in a new tab).

Login on the next page.

Order History (text link) to the left.

There should be links on your order history.

Keep an eye on eBay, for a UK seller, who offers new/clone 4MB GVP SIMM32 . They post a few modules every so often. 'GVP SIMM' can be your search.

I saw a different seller in the UK offering a used 16MB module when I looked just a bit ago. That module, while it technically would give you 4MB more if placed in the last (lower-most) socket, it would not offer you the full 16MB amount more. The card only supports the 4MB sized modules.

Please ignore the seller with the more than 10x overpriced 4MB module they are associating with the video toaster.

There was also a 1MB module from Germany - that is not what you want. The speed of the RAM parts is also not a match for your board.

The G-Force 030 card is placing the first 2x 4MB banks into the 8M AutoConfig space. This leaves no room for the Supra 4MB 16-bit. I suspect it doesn't like being ShutUp by the AutoConfig process, thereby disturbing the (assumed) next downstream X-Surf card in the configuration sequence.

There is technically a way to get the 16-bit RAM to fit with some SIMM32 bank shuffling, but as Jens pointed out, the 16-bit RAM is not an asset. Sell the Supra board, and pick up a 4MB GVP SIMM32, and you have your extra 4MB, no conflict (it will map high with the 3rd SIMM32 module), and it will all be 32-bit RAM.

Thanks shan2754.

I did reply with a direct message - let me know if you did/didn't get it.

If not, e-mail is my name @ Yahoo

The MKIII wasn't on my got-to-have list, but an opportunity for a deinterlacer for my A1200 is of interest. USA/Rhode Island here.

After you purchase - you get somethin like 20 or more downloads for whatever is the current release/update. If it updates next week, you can get that one.

You find the download link in your Order history after purchase.

There is a time frame the link is valid - I think it's ~1yr.

As I recall, I first bought P96 back in July of 2021. It expired a year later in 2022. I renewed it again back in December.

The motherboard was likely already modified to support 1MB ChipRAM setting.

Some 3rd party trap door expansions have that jumper/switch for compatibility with some games which didn't follow the rules, and may expect a different memory footprint.

OS 3.2.1 - there is a ShowConfig tool. You can see the memory ranges the OS knows about.

See if there is a 512K Fast memory space showing at $00C0.0000 - that is where the trapdoor memory appears if the 1M ChipRAM modification has not been done. When done, it extends the 512K ChipRAM from $0000.0000-007F.FFFF to $0000.0000-00FF.FFFF. (The '.' is added here for readability, and won't be in the actual output).

The modification is a pad gets opened, and another 3-pin position moves to the 'other position'. Online information has the detail. Best done by someone with some experience in soldering.

One of the things we didn't have back in the day was an alternative FS to FastFileSystem. In a sense, it was all about using FFS instead of OFS (the native floppy FS) from the get-go back then. I think it was even Gerard Bucas (President/Fmr C= VP prior) that hashed out the pre-1.3 RDB+FFS that GVP used in 1987, and C= ended up tweaking the idea for the HDToolBox/A2091/A590 boot block (the A2090a used a boot block, but OFS in the ROM, until 2.0 and the discontinued the A2090/a.)

One of the things we never had in FastPrep/ExpertPrep is picking alternative file systems. Having a Buddah now, I have a better feel for what is involved. I have the source for Fast/ExpertPrep, but have had no time to add the things that it needs. Maybe one day.

I wish I recall more of what I tried and failed to do with the Buddah when I first tried to prep a disk/media on it. I'd pass it along. I didn't think to seek out support then as I knew I would figure it out eventually - and did.