What do think will be easiest, writing a new software that works similar to the linked one, but with support for modern chips, or trying to adapt this one?
For me, it probably depends on how far we need to go with software mods. I'm not sure if I'll actually have time to do much with this other than just hacking the software to the bare minimum needed to get it working. I think it would be fun to get this actual utility working just for the sake of being able to see what it was like. I guess another option would be to design a socketed clone of the Lobos board and program the chips in a standard ROM programmer like the XGecu T56. (My SIMM programmer can't do it because these chips need VPP and of course the /CS and /WE pinout doesn't match anyway)
Does the software probes the ROM at all, or rely on the Slot Manager to identify the Flash devices? Or does it assumes it's there if the user tells it so?
As far as I can tell, it's not doing anything with Slot Manager. When you first launch it, the software goes one by one through the big table of flash cards twice: once to identify if there's a SIMM installed, and once to identify if there's a PDS card installed. It's just blindly attempting write and read cycle combinations to put the chips into identification mode and read the manufacturer and product ID. If it finds matching manufacturer and product IDs, it knows something supported is installed. Also, when looking for a PDS card, it temporarily installs a custom bus error handler and attempts a read first. If the custom bus error handler executes, it knows the card isn't installed and moves onto the next entry in the table without ever attempting any write cycles.
Mapping the physical addresses to themselves shouldn't be needed
True, at least not for the slot addresses. The program's use of transparent translation is probably more important for handling the onboard ROM/ROM SIMM addresses. The Quadra ROMs only map a small amount of the available ROM space using the MMU, from 0x40800000 to the length of the ROM. But this software does write cycles to 0x40400000 (or 0x40200000 on the LC III), which wouldn't be mapped through the default MMU setup without using TT0. The only reason I'm familiar with this issue is because I had to help
@Jockelill with reconfiguring the MMU tables in order to gain access to the full 8 MB of available ROM SIMM space for the ROM disk driver.
Using a NOT gate would mean you wouldn't need to hack the utility or worry about ROM accesses.
Ahh, I misunderstood what you were suggesting with the NOT gate. The way you have the NOT gates in the schematic you made (it's beautiful!) does make perfect sense if you want to keep both halves of the SIMM mapped at once. I was envisioning it more like a physical switch that chooses whether you're looking at the top or bottom half of the chips (pulldown resistor on the chip's highest address line, switch shorts it to 5V). The switch would just directly control the highest address lines of the chips. So with the solution I had been envisioning in my head, both halves wouldn't actually be mapped into the ROM space simultaneously. I think your solution is better, the only drawback being that it cuts the usable ROM space in half.
There's still a tiny bit of software support needed for your solution that keeps both halves mapped simultaneously, although it's a lot easier than the software support that would be needed for what I was thinking of. For your solution: if you're trying to program the half of the SIMM that you don't currently have selected (e.g. you're recovering from a bad flash), you have to change the addresses you're writing to accordingly. For example let's pretend it is a 2 MB SIMM containing two 1 MB halves. If you're booted from the lower half and trying to program the lower half, you want to write to 0x40800000. But if you're booted from the upper half (so it's currently mapped as the lower half) and you want to write the lower half (which is currently mapped as the upper half) you need to write to 0x40900000 instead. So the software doing the writing would have to be aware of that difference. Either way, this definitely sounds much easier than what I originally proposed about making sure you're executing from RAM and then asking the user to physically flip the switch on the SIMM.
It identifies my ROM as "read only" most likely due to the fact that it cannot regonize the chips.
Yes, that's correct. It's attempting write cycles and seeing if the chips respond as the various IDs that I listed above. You can confirm this by watching for brief low pulses on SIMM pin 3 with an oscilloscope when you open the flasher app. (Just be careful because 12V on pin 2 is right next to it!)
During my short testing I also did what one never should do, I took out the ROM simm and put in another one with whole system running!! My approach was, "what if I can insert another ROM and reprogram it", but the whole system hangs.
Eek! This is exactly what I was referring to when I was saying that my first "2 bank" solution would require software that gave the user time to flip the switch -- you can't flip away from the working ROM until you're sure you're not executing anything in ROM anymore. Also, that sounds incredibly dangerous to yank out the SIMM while it's powered!
I actually have a period flash ROM from a Apple Interactive TV system, but the problem is that as it is it will only boot in a Apple interactive TV system
Yeah -- if you had some way to externally program it with an actual LC 475 compatible ROM image, I'm confident it would show up correctly as a programmable SIMM in this software.
if your disk is full it tells you "disk full" and then you need to click on "Duh"
. Don't say they didn't have humor.
Haha, yep! I noticed that. There are some other fun gems in there too. I haven't seen the message, but in the code if it can't open an image file it will say "Could not open image file" with a button of "Oh well".
I would think the PDS portion would just be for ROMs on PDS cards
I wish we had some examples of these cards somewhere. Sounds very interesting!
There's also the checks for EDisk and Ginty ROM disks a bit later.
I stumbled upon the Ginty stuff while disassembling the Color Classic ROM. There are also some interesting comments in the leaked source about this with V8/VISA based machines, where it looks for the ROM disk, then flips some bits in a register and tries again, then flips the bits back if it didn't find anything. The interesting comment there in the code is "we need to do this because we cannot tell if we have a PDS/PCMCIA flash card installed or a ROM exp. SIMM. With this bit cleared no DSACK is generated by the ASIC and with it set DSACK is generated by the PDS card attached." I wish I understood what was going on there...
