Yes, that is exciting!Charles MacDonald wrote:The Sega CD results were quite exciting.Chilly Willy wrote:No rush. Whenever is fine.
I wrote a memory map viewing program that runs out of work RAM, and used the devcart to toggle the /CART pin under software control. Both the cart RAM and Sega CD RAM/ROM/registers were at the right places, with no conflicts, in either state.
Yes, that's what MegaCart does. In fact, all it does since it doesn't have a USB interface.I then tried jumping to the BIOS reset vector and it worked. I tested several games which all ran fine (including special graphics effects) while the cart RAM was at $400000-$7FFFFF and cart registers at $A13001-$A130FF were enabled. Two possibilities spring to mind:
1. You could load ROMs off a CD-R into RAM. Sure it's slower than loading from USB, but why not.
Which would really save on CDRs and wear and tear on the SCD.2. Since you can boot from a cartridge you could do Sega CD development without ever burning a disc, and the USB connection could be used to load files from the host PC. This could simplify development until it was time to switch over to CD access and the data files were more finalized and ready to go on a CD. Granted the files are coming in at the wrong side (Genesis 68K instead of Sega CD 68K) and you'd probably need to either make a boot disc so the BIOS could load, or determine the BIOS state and preset the system to match for a pure cart-only boot.
I don't know off-hand which signals the 32X uses... you might try talking to KRIKzz about that as I know he ran into some initial trouble with the 32X on his dev cart that he worked out. He might be willing to share some info.The bad news is that the 32X does not work. There is some graphics corruption and the machine hangs shortly. I feel certain it is having trouble reading ROM data and is loading corrupt data and program code into memory. When acting as a pass-through device for Genesis games loaded onto the devcart, everything works perfectly.
I looked at some 32X cartridges and they use CE0 and CAS0 exclusively for ROM access, and I use those signals too. But I now realize the 32X adapter may use the other signals (ASEL, CAS2, etc.) which I did not account for. Oops. It could also be a speed issue but I deliberately used the fastest RAMs and buffers I could find.
I was going to mention speed as I know the 32X by default uses a much faster cycle time on the rom access than the MD does. It could still be a timing issue - you are probably designing the cart around 68000 bus cycles... take a look at the SH2 bus cycles in the SH2 hardware manual and make sure you meet setup and hold times and the like. The SH2 does a "standard" two clock cycle access with a (minimum of) five clock wait for accessing the cart rom. I plan to do some experiments on the NeoFlash MD Myth cart to see if I can drop that wait period down for faster Myth access on the 32X. That wait period is programmable.
You have to enable the adapter to access the 32X resources from the MD, but you don't have to use the SH2s. The SH2 reset is separate from the adapter enable, and you can leave the SH2s reset. That is what BEX does for their 32X examples - they simply enable the adapter and use the resources from the MD side for better graphics. You have to clear b15 of 0xA15100 to access any VDP assets from the MD.The memory map viewer (when $A15100=$0001) shows the vector ROM, fixed ROM, banked ROM, and MARS ID, but hangs when I do word reads from the frame buffer, overwrite image, or palette RAM. I didn't initialize any other registers in case that is necessary.
The adapter enable allows the MD to access all the rest of the 32X spaces besides the "MARS" register. The SH2 reset is a different bit... 0xA15100 (WORD) b0 = ADEN (1 = enabled), b1= /RESET (0 = reset asserted), and b15 = FM (0 = MD access, 1 = SH2 access).ADEN seems to control the /TIME signal on the 32X cartridge port.
When ADEN=0 I can see my other hardware at $A130xx along with the MARS ID. I have pull-up resistors on VD0-VD7 so all unused locations are $00FF. When ADEN=1 every byte is zero except for the four MARS ID bytes.
This would imply having to toggle ADEN every time you want to access extra hardware in the $A130xx range. Does that do anything bad like reset the SH-2s or clear register settings, etc?
By the way, when the Master SH2 doesn't detect a valid IP block in the rom, it sits in a loop continuously setting FM to 1 so that the 32X cannot be used by the MD. The only way to both enable the 32X AND use the SH2s (when there is a cart) is to have a valid IP block. If the CART line isn't asserted, the Master SH2 goes into a loop waiting for _CD_ to be stored to the COMM0 register by the MD; that indicates a valid boot block for the SH2 has been stored to the framebuffer by the MD passed to it by the SCD. That's how CD32X works.
Very clever indeed.You got me curious about this, and it turns out somebody at Sega wrote some very clever code!The addresses were set by SEGA for their DevCart, and may or may not be fully decoded depending on what they use. Clearly, if they use the bank regs, they need to decode at least a LITTLE more.
They do all the ROM bank register writes first, and the $A130F1 write last. After that point the game only ever writes to $A130F1. So even though the SRAM banking value is modified during the ROM bank writes, the final SRAM control write sets the correct value. This way the same code sequence has the desired effect both with and without the ROM banking hardware present.
I don't know that... it's an interesting problem to consider - if they assert CART so it boots a custom bios, then the CD hardware is all at the wrong place on the MD side. If I had to guess, they assert CART, boot far enough to load a modified SCD bios into SCD program ram, then flip the CART line back and continue to boot as normal. But that's just my guess on the matter.Off-topic: Do we know how the Sega CD import-enabling cartridges work? If it's just a software thing I wonder if I could implement that functionality into my devcart.
