Page 1 of 1
68K Memory access
Posted: Tue Jan 19, 2021 8:44 pm
by mickagame
I have a question about how the genesis component work.
If i don't a misunderstanding a genesis cardridge has his internal adress decoder.
All 24 pins of the adress bus is connected to a cartridge and the cartridge can be mapped to all 68k Memory Space
=> This is correct?
Re: 68K Memory access
Posted: Wed Jan 20, 2021 9:48 am
by ob1
I'm not sure I correctly understood your question, but there is this block diagram that I like very much :
(this diagram states that the address bus is 16 bits, but I'm pretty sure it is 24 bits).
Here, you can see that the cartridge is on the 68000 bus.
Plus, when you take a look a the memory map, the ROM is fully mapped into the 68k (00 0000h - 3F FFFFh).
So,
"All 24 pins of the adress bus is connected to a cartridge"
Not sure about the physical connections but ...
"the cartridge can be mapped to all 68k Memory Space"
Yes Sir!
Hope it helps.
Re: 68K Memory access
Posted: Wed Jan 20, 2021 9:52 am
by ob1
Re: 68K Memory access
Posted: Wed Jan 20, 2021 7:15 pm
by mickagame
thanks for the reply.
So technically the system plugged into the cartridge port could reply to a read/write event adressed to a vdp for example (instead of the vdp himself)?
Re: 68K Memory access
Posted: Thu Jan 21, 2021 6:57 pm
by Mask of Destiny
The cart can't stop the hardware in the console from responding, so it is generally not proper to respond to a read from an address that the console already does. If you want to be compatible with the Sega CD and 32X, you also need to avoid the address ranges they use. The Teradrive additionally uses some more of the address space as well (though those are pretty rare).
mickagame wrote: ↑Tue Jan 19, 2021 8:44 pm
If i don't a misunderstanding a genesis cardridge has his internal adress decoder.
Most carts don't actually. The console has an internal address decoder that drives two chip selects the cart can use !CE0 (asserted for the bottom 4MB of the address space) and !TIME (asserted from A13000 to A130FF). Of course, you can ignore those and do your own decoding, but I wouldn't recommend it outside of mapping to unused regions outside of the normal range. Not using !CE0 can mean that you get into a bus fight with the TMSS ROM on consoles that have it.
Additionally, for some address ranges you will need to drive !DTAK low as the hardware in the console doesn't do it for you for the entire address space. Note that this signal is open drain so should never been driven high.
Re: 68K Memory access
Posted: Sun Jan 24, 2021 11:18 am
by MrD
Most carts don't actually. The console has an internal address decoder that drives two chip selects the cart can use !CE0 (asserted for the bottom 4MB of the address space) and !TIME (asserted from A13000 to A130FF). Of course, you can ignore those and do your own decoding, but I wouldn't recommend it outside of mapping to unused regions outside of the normal range. Not using !CE0 can mean that you get into a bus fight with the TMSS ROM on consoles that have it.
Also not using the console's own enable lines means your cartridge will ignore VDP activity!
I learned the hard way 
Re: 68K Memory access
Posted: Wed Jan 27, 2021 6:48 am
by mickagame
Mask of Destiny wrote: ↑Thu Jan 21, 2021 6:57 pm
The cart can't stop the hardware in the console from responding, so it is generally not proper to respond to a read from an address that the console already does. If you want to be compatible with the Sega CD and 32X, you also need to avoid the address ranges they use. The Teradrive additionally uses some more of the address space as well (though those are pretty rare).
mickagame wrote: ↑Tue Jan 19, 2021 8:44 pm
If i don't a misunderstanding a genesis cardridge has his internal adress decoder.
Most carts don't actually. The console has an internal address decoder that drives two chip selects the cart can use !CE0 (asserted for the bottom 4MB of the address space) and !TIME (asserted from A13000 to A130FF). Of course, you can ignore those and do your own decoding, but I wouldn't recommend it outside of mapping to unused regions outside of the normal range. Not using !CE0 can mean that you get into a bus fight with the TMSS ROM on consoles that have it.
Additionally, for some address ranges you will need to drive !DTAK low as the hardware in the console doesn't do it for you for the entire address space. Note that this signal is open drain so should never been driven high.
In my free time i work on a genesis emulator. In the system i design the cart inserted can declare the memory adress range for wich the sytem have to call it.
In traditionnal emulator the address decoding is something like :
if (address < 0x400000)
data = cart_port-> read(address)
With this system if you want to map extra hardware on unused adress range you can't because the adress decoding is limited to this range.
In my system you can create a class for a special cartridge (for example) and when you will insert it (megadrive.insert(cartridge)) it will give to the genesis all adress range it can respond.
But if the adress range is already taken on the bus the megadrive class will respond an error.
This is accurate or unusual?
There is this post speaking about it too :
https://gendev.spritesmind.net/forum/vi ... php?t=1283
Re: 68K Memory access
Posted: Tue Feb 09, 2021 8:14 pm
by mickagame
When 68K perform long write/read, the 68K in reality do 2 words access.
In what sequence does it?
1) Address + 0
2) Address + 2
Or
1) Address + 2
2) Address + 0
?
Re: 68K Memory access
Posted: Wed Feb 10, 2021 6:41 am
by Mask of Destiny
mickagame wrote: ↑Tue Feb 09, 2021 8:14 pm
In what sequence does it?
1) Address + 0
2) Address + 2
Or
1) Address + 2
2) Address + 0
It depends. Reads are always done the first way. Writes are usually done the first way as well, but the destination of a move instruction is written the second way UNLESS it's using the predecrement addressing mode.
Re: 68K Memory access
Posted: Mon Feb 15, 2021 6:29 pm
by Gigasoft
Instructions that perform accesses in reverse order are:
- movem.l to -(Am)
- move.l to -(Am)
- eori.l, ori.l, andi.l, subi.l, addi.l, subq.l and addq.l to memory
- negx.l, clr.l, neg.l, not.l on memory
- subx.l and addx.l -(An), -(Am), both reading and writing
All other accesses happen in forward order.
