Page 3 of 4

Re: QL Add-on ROM

Posted: Fri Mar 27, 2020 3:23 pm
by tcat
Hi,

Thank you.
I will probably go with $C0000 address decode, as I do not have wired A17 line, so it may be easier, also this way I could use up to half of the EEPROM capacity 256K.

In the glue logic, I drive both RAM /OE and /CS with GAL's /RAMCE pin. CPU R/W is connected directly to RAM /WE.

I am not sure I can do the same for EEPROM with /ROM_CE, reading specs now.
write operation
write operation
Also sector erase and program are lengthy operations, where the chip status has to polled until operation complete.
timings
timings
Many thanks
Tomas

Re: QL Add-on ROM

Posted: Fri Mar 27, 2020 4:52 pm
by Pr0f
You won't be able to 'flash it' without some additional logic or timing within a program. But if preprogrammed, it can work the same way as an eprom/rom chip, so WE would just be wired to 5v for that.

Re: QL Add-on ROM

Posted: Sat Mar 28, 2020 10:18 am
by tcat
Hi,

Yes, EDIT preprogramming the flash outside the QL machine, seems easiest. To act as a ROM inside QL, /WE is then fix wired to be kept high. I have seen various circuits on the net, that use a diode (IN4148), probably to pull signal high or low, or initiate some delay on power on. Still do not get the idea fully, not sure if applicable here?

Also this solves `chicken & egg' problem, as an uninitialised EEPROM with random or zero data, would fail linking during boot in a crash, am I right?.

On the other hand, programming or sector erase sequence does not seem complicated, only needs to be tied to the decoded address $C0000 in the assembly routine, somehow.

Program sequence:

Code: Select all

write data $AA to address $555 \
write data $55 to address $2AA  > init sequence
write data $A0 to address $555 /
write user data $XX to user address $YYYYY
Instead of status polling, I thought we could wait in a delay loop, and verify the whole sector afterwards, reprogramming failing bytes, if any. Not sure if good idea.

Tomas

Re: QL Add-on ROM

Posted: Sat Mar 28, 2020 4:14 pm
by Dave
I have programmed flash off the QL bus, during multi-tasking, without problems. If you recall my idea a few years ago of having multiple CPUs mapped through dual port SRAM to areas of the QL's memory map, I did a fair amount of work on it. I ended up using a small flash as a persistent system-programmable address decoder. I ended up having three 68SEC000 running at 40MHz each, each with it's own DPRAM Io window into the QL, and 512K of private RAM. I was able to program the flash from BASIC, because the device had a buffer to store the entire block being programmed. You'd do the set-up writes, write the block, sign off and it would only then go off and write the block. You'd poll it waiting for it to acknowledge the write had completed.

I raise this because I suggest that if you add a PLCC 68000 and Minerva to the card (almost no extra complexity at all, even if it sounds daunting) you'd gain a much larger memory map.

That's basically what the 4M RAM card is: a 68000 with two extra address lines, 4M DRAM and a refresh system alongside the new address decoder logic which disabling the internal CPU.

Re: QL Add-on ROM

Posted: Sat Mar 28, 2020 8:55 pm
by Nasta
There are only a few types of flash chips that support 'read while write' operation.
Some do support it in a limited manner, in that you can be writing one of it's sectors while reading another. Most do not, and when the flash chip is switched over to write mode, the whole chip (all sectors) is in write mode and code/data cannot be read from it.
To this end you can't reliably write a flash containing basic extensions in basic, let alone an OS ROM unless it's running from a RAM copy. Not even if you are not using the extensions as there might be other code there linked into the basic interpreter.
One way to do it safely is to load an image into RAM, then use code in RAM to copy it to flash.
Some flash chips also require accessing some locations that would require them to be mapped into memory to places where other things should be. So, ultimately, it's a question of choosing the right flash chip, and mapping it into the right place.

Re: QL Add-on ROM

Posted: Sun Mar 29, 2020 9:26 am
by tcat
Hi All,

Many thanks for useful arguments.

I wish to explore in theory, what I could do with `29F040', fitted in a daughter board above `Simple RAM' based on `AS6C4008', if proved possible to program right on QL bus.

It should serve primarily as read only media, holding extensions mentioned earlier. On occasions, reprogrammed by sector, `en masse'.

My concern is how to drive /WE, /OE of `29F040', what GAL inputs and equations need be added???

(NOTE this may differ to SRAM AS6C4008, where /OE /CE are both driven with GAL /RAMCE pin, while /WE connects right to CPU R/W)

I was advised of address decode and /CE, by Prof already.

/ROM_CE connects to /CE

Code: Select all

  VALID_ROM = A19 * A18  # $C0000
  ROM_CE = VALID_ROM * DS
 
  IF( VALID_ROM )  #tristate
  DSMCL = 1

  IF( VALID_ROM * DS ) #tristate
  DTACK = 1
Do I need tristate equations on read only device above, linked during boot?

Thank you so far.
Tomas

Re: QL Add-on ROM

Posted: Sun Mar 29, 2020 5:06 pm
by tcat
Hi,

Thinking further. On AM29F040 /OE seems complementing /WE as per the specs.

While CPU R/W (RDWL) could wire directly to /WE, /OE needs to be inverted.
This may require extra RW GAL input, correct, could this work?

Code: Select all

  VALID_ROM = A19 * A18  # $C0000
  ROM_CE = VALID_ROM * DS
 
  IF( VALID_ROM )
  DSMCL = 1

  IF( VALID_ROM * DS )
  DTACK = 1
  
  ROM_OE = /RW
Many thanks

Re: QL Add-on ROM

Posted: Mon Mar 30, 2020 6:44 pm
by Dave
May I propose thinking about this in a slightly different way?

What if instead of a flash IC (20 year retention guarantee) you used a 128K low power SRAM and CR2032 battery as back-up power? In standby, the SRAM would retain contents using microAmps. The battery would last 15 or 20 years. If you splurged and put two CR2032 holders on it, you could safely replace one battery then the other without loss of data. It would outlast your lifetime anyway.

If you did this, it would make it a matter of defaulting to not allowing writes to that SRAM. You could do this by using a flip-flop in your decoder GAL, and requiring a poke to a specific address to enable/disable write capability.

When I did this, an odd value would enable writes and an even value disable writes - so only D0 would need to be added to the decoder inputs.

This simplifies everything.

Re: QL Add-on ROM

Posted: Mon Mar 30, 2020 7:43 pm
by tcat
Hi Dave,

I see your point, battery backed SRAM, similar to what Martin has proposed. This flip-flop is a write-protection trigger, right? As I believe just to write enable, SDWL signal should suffice or not?

Many thanks for taking your interest.
Tomas

Re: QL Add-on ROM

Posted: Tue Mar 31, 2020 7:31 am
by Dave
You could have a physical witch to connect /WR. If you tie it to 5V it can’t be written. A mechanical pull-up.