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 8324 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 8059 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.

[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...

[keli]

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...

From my playing around with FPGAs and the ST bus, I have found out that for reads, always putting 16 bits of data on the bus when either /LDS or /UDS are active low works perfectly fine. It's only when writing you have to be careful only to grab the correct bits, as the CPU will only be driving the corresponding half of the data bus. This is of course irrelevant for a ROM as you will only ever see read cycles. (The GLUE will produce a bus error if the CPU tries to write to the address space assigned to the cartridge port, and the cartridge port does not have a /WE pin anyway.)

[exxos]

From my playing around with FPGAs and the ST bus, I have found out that for reads, always putting 16 bits of data on the bus when either /LDS or /UDS are active low works perfectly fine. It's only when writing you have to be careful only to grab the correct bits, as the CPU will only be driving the corresponding half of the data bus. This is of course irrelevant for a ROM as you will only ever see read cycles. (The GLUE will produce a bus error if the CPU tries to write to the address space assigned to the cartridge port, and the cartridge port does not have a /WE pin anyway.)

Yeah I think it should be ok.

I was going to just use LDS, but that would limit to 16bit only reads to the cartridge.. I don't know what Arne did, his diagram shows 2x 8bit roms. So if he ignored UDS, then parts of the diagnostic cart may not work as it wouldn't be able to do 8bit reads