16BIT ROM CART THOUGHTS

[exxos]

I have been thinking about the diagnostic cart where larger ROM's are used with a switch to select which version of the ROM to run (IE, ST, STE, MSTE etc). What bugged me is it used 2 chips. So I thought about using a single PLCC ROM 4096 instead. Can fit a few ROM's in there anyway , and it only needs one.

I was looking at this...

rom_cart.JPG (176.95 KiB) Viewed 3085 times

Where I am making the assumption that ROM4 wouldn't be used.

What actually bugs me , is UDS & LDS. I am making the assumption that even if the ST read in 8bit modes, a 16bit ROM could still be used, it would still output the data on the 16bit bus, just the CPU would ignore the 8 bits output by the ROM depending on UDS LDS.

Though I do not know , but assume again, the ST will read the 16bits in one go, by having LDS & UDS low during ROM read.

The problem here is, I think either way, it would need something like the LS11 as used in the STFM ROM circuit. In that LDS or UDS is low to enable the 4096 ROM, OR, UDS & LDS are both low to enable the 4096 ROM.

Though does anyone know if the ST would be reading in 16bit or 8 bit on the cartridge port ?

If it does read in 16bit, then LDS & UDS will go low at the same time, and I could probably get away with using LDS for CE, and ignore UDS. Not pretty, but would work assuming 16bit access.

8bit access I think would have to use something like the LDS11 to drive the 4096 CE on UDS or LDS low , in which case its probably not really worth designing a PLCC 16bit ROM cartridge if 2 IC's are going to have to be used anyway

[rpineau]

When the 68000 does a 8 bit read, it asserts the proper uds/lds signals but you can indeed place 16bits of data on the bus and the CPU will read what it needs.
You just need to make sure the ROM is selected for /UDS or /LDS (via an and gate for example as you said.).
Rodolphe

[exxos]

When the 68000 does a 8 bit read, it asserts the proper uds/lds signals but you can indeed place 16bits of data on the bus and the CPU will read what it needs.

Yes that is what I thought...

You just need to make sure the ROM is selected for /UDS or /LDS (via an and gate for example as you said.).

Yeah, though if the CPU is doing 16bit read, then I could cheat and use either UDS or LDS.. I guess I would have to connect up my scope and check LDS, UDS to see if its doing 16bit read to ROM.. I would assume the CPU would for ROM port.. but as you know, can't assuming anything with this Atari stuff

[rpineau]

Yep.
It's not so much what the CPU does but what the code does. If the code does a 8 bit access for some reason, it will use /LDS or UDS (depending on the address).
The code part will always be read as 16bit as this is the minimum instruction size. The data can be read in 8 or 16 bits depending on what the code is doing.
Rodolphe

[exxos]

True.. I guess I will get my scope on the diagnostic cart, at least the ST one anyway, see if I can spot it doing any 8bit access.

[exxos]

Yep.
It's not so much what the CPU does but what the code does. If the code does a 8 bit access for some reason, it will use /LDS or UDS (depending on the address).
The code part will always be read as 16bit as this is the minimum instruction size. The data can be read in 8 or 16 bits depending on what the code is doing.

I forgot all about this. Though even if we did put 16bit data on bus from ROM all the time , the CPU is only going to read high or low byte anyway. So would it actually matter ?

I wonder this as...

cart1.JPG (79.54 KiB) Viewed 2820 times

I am on 4 layers now and having issue routing it. Even auto-router makes usual mess but says 100% complete, then decides several tracks are broken so it fails. Would be a lot easier to route a single 16bit ROM.

[Petari]

"If it does read in 16bit, then LDS & UDS will go low at the same time, and I could probably get away with using LDS for CE, and ignore UDS. Not pretty, but would work assuming 16bit access. "
CPU will ignore lower or higher 8 bits if only UDS or LDS is asserted. But you can not ignore UDS - because it may happen that there is byte (8 bit) access on even address (when reading some data, and not opcode) - and then only UDS is activated. So, need logic for CE. what can be even 2 diodes + 1 resistor.

[exxos]

"If it does read in 16bit, then LDS & UDS will go low at the same time, and I could probably get away with using LDS for CE, and ignore UDS. Not pretty, but would work assuming 16bit access. "
CPU will ignore lower or higher 8 bits if only UDS or LDS is asserted. But you can not ignore UDS - because it may happen that there is byte (8 bit) access on even address (when reading some data, and not opcode) - and then only UDS is activated. So, need logic for CE. what can be even 2 diodes + 1 resistor.

Yeah, I am thinking similar, 2 diodes so either UDS or LDS goes low, it will pull ROM CE low.. so it will enable ROM on 16 or 8 bit access.

[troed]

I have been thinking about the diagnostic cart where larger ROM's are used with a switch to select which version of the ROM to run (IE, ST, STE, MSTE etc). What bugged me is it used 2 chips.

Arne's cart doesn't use two chips? Or is that very long DIL EPROM the functional equivalent of two?

http://atari.team-yankee.net/pages/bake ... tkit-5.php

[exxos]

Arne's cart doesn't use two chips? Or is that very long DIL EPROM the functional equivalent of two?

Yeah, though the question is if it works with 8bit code (serial port). Its no problem to use a 16bit ROM (like I do with my ROM kits) but the cartridge uses UDS and LDS (8bit high and low byte) , but with 1 chip we only have 1 chip enable, so we can't use UDS and LDS as enable lines (like original cartridge does) .

Basically ...

Original cart (2x8bit rom) :
UDS > chip enable 1
LDS > chip enable 2

16bit ROM:
UDS or LDS > chip enable.

So as peter says, we can use LDS OR UDS to switch the ROM's chip enable lines low.. but the question is, does that break anything...

My question was that I don't think it would matter, as the CPU will only read high or low byte from the bus anyway, so if we put 16bit data on the bus, it shouldn't matter... This is what I really want to confirm before I start building a 16bit ROM cart...