New devcart

For hardware talk only (please avoid ROM dumper stuff)
Chilly Willy
Very interested
Posts: 2736
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Jan 23, 2011 8:55 pm

Charles MacDonald wrote:
Chilly Willy wrote:No rush. Whenever is fine.
The Sega CD results were quite exciting. :D

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 is exciting! :D

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.
Yes, that's what MegaCart does. In fact, all it does since it doesn't have a USB interface.

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.
Which would really save on CDRs and wear and tear on the SCD. :)

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

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.

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

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

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.

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.
You got me curious about this, and it turns out somebody at Sega wrote some very clever code!

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.
Very clever indeed. :)

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

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Sun Jan 23, 2011 11:51 pm

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


I think you are right. I tried plugging a Game Genie between several 32X games and the system and got similar graphics corruption. The Genie passes every signal through and only delays CE0# slightly. So definitely a timing issue.

On a logic analyzer the ROM accesses are about half as long as the 68000 ones. I'm using quite fast RAM but now see the buffers are enabled too slowly. I may be able to shave 20ns off or so but running within such a tight margin is bound to fail eventually. The SH2s just run too fast.
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.
That must be the problem, I'll try including a valid IP block and see if things work better.

Chilly Willy
Very interested
Posts: 2736
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jan 24, 2011 12:47 am

Charles MacDonald wrote:
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


I think you are right. I tried plugging a Game Genie between several 32X games and the system and got similar graphics corruption. The Genie passes every signal through and only delays CE0# slightly. So definitely a timing issue.

On a logic analyzer the ROM accesses are about half as long as the 68000 ones. I'm using quite fast RAM but now see the buffers are enabled too slowly. I may be able to shave 20ns off or so but running within such a tight margin is bound to fail eventually. The SH2s just run too fast.
I've never heard anyone say the 32X runs TOO FAST before. :lol:
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.
That must be the problem, I'll try including a valid IP block and see if things work better.


I just figured you were testing using a 32X image loaded into the ram. If you were just running test code that turned on the 32X and deasserted the SH2 reset, you would DEFINITELY run into this problem. The IP block is from 0x3F0 to 0x7FF and has to match byte-for-byte or it fails. Here's the relevant block I use in Wolf32X:

Code: Select all

| Standard Mars startup code at 0x3F0 - this is included as binary as SEGA
| uses this as a security key. US law allows us to include this as-is because
| it's used for security. The interoperability clauses in the law state this
| trumps copyright... and the Supreme Court agrees. :P

        .word   0x287C,0xFFFF,0xFFC0,0x23FC,0x0000,0x0000,0x00A1,0x5128
        .word   0x46FC,0x2700,0x4BF9,0x00A1,0x0000,0x7001,0x0CAD,0x4D41
        .word   0x5253,0x30EC,0x6600,0x03E6,0x082D,0x0007,0x5101,0x67F8
        .word   0x4AAD,0x0008,0x6710,0x4A6D,0x000C,0x670A,0x082D,0x0000
        .word   0x5101,0x6600,0x03B8,0x102D,0x0001,0x0200,0x000F,0x6706
        .word   0x2B78,0x055A,0x4000,0x7200,0x2C41,0x4E66,0x41F9,0x0000
        .word   0x04D4,0x6100,0x0152,0x6100,0x0176,0x47F9,0x0000,0x04E8
        .word   0x43F9,0x00A0,0x0000,0x45F9,0x00C0,0x0011,0x3E3C,0x0100
        .word   0x7000,0x3B47,0x1100,0x3B47,0x1200,0x012D,0x1100,0x66FA
        .word   0x7425,0x12DB,0x51CA,0xFFFC,0x3B40,0x1200,0x3B40,0x1100
        .word   0x3B47,0x1200,0x149B,0x149B,0x149B,0x149B,0x41F9,0x0000
        .word   0x04C0,0x43F9,0x00FF,0x0000,0x22D8,0x22D8,0x22D8,0x22D8
        .word   0x22D8,0x22D8,0x22D8,0x22D8,0x41F9,0x00FF,0x0000,0x4ED0
        .word   0x1B7C,0x0001,0x5101,0x41F9,0x0000,0x06BC,0xD1FC,0x0088
        .word   0x0000,0x4ED0,0x0404,0x303C,0x076C,0x0000,0x0000,0xFF00
        .word   0x8137,0x0002,0x0100,0x0000,0xAF01,0xD91F,0x1127,0x0021
        .word   0x2600,0xF977,0xEDB0,0xDDE1,0xFDE1,0xED47,0xED4F,0xD1E1
        .word   0xF108,0xD9C1,0xD1E1,0xF1F9,0xF3ED,0x5636,0xE9E9,0x9FBF
        .word   0xDFFF,0x4D41,0x5253,0x2049,0x6E69,0x7469,0x616C,0x2026
        .word   0x2053,0x6563,0x7572,0x6974,0x7920,0x5072,0x6F67,0x7261
        .word   0x6D20,0x2020,0x2020,0x2020,0x2020,0x2043,0x6172,0x7472
        .word   0x6964,0x6765,0x2056,0x6572,0x7369,0x6F6E,0x2020,0x2020
        .word   0x436F,0x7079,0x7269,0x6768,0x7420,0x5345,0x4741,0x2045
        .word   0x4E54,0x4552,0x5052,0x4953,0x4553,0x2C4C,0x5444,0x2E20
        .word   0x3139,0x3934,0x2020,0x2020,0x2020,0x2020,0x2020,0x2020
        .word   0x2020,0x2020,0x2020,0x2020,0x2020,0x2020,0x2020,0x2020
        .word   0x2020,0x2020,0x2020,0x524F,0x4D20,0x5665,0x7273,0x696F
        .word   0x6E20,0x312E,0x3000,0x48E7,0xC040,0x43F9,0x00C0,0x0004
        .word   0x3011,0x303C,0x8000,0x323C,0x0100,0x3E3C,0x0012,0x1018
        .word   0x3280,0xD041,0x51CF,0xFFF8,0x4CDF,0x0203,0x4E75,0x48E7
        .word   0x81C0,0x41F9,0x0000,0x063E,0x43F9,0x00C0,0x0004,0x3298
        .word   0x3298,0x3298,0x3298,0x3298,0x3298,0x3298,0x2298,0x3341
        .word   0xFFFC,0x3011,0x0800,0x0001,0x66F8,0x3298,0x3298,0x7000
        .word   0x22BC,0xC000,0x0000,0x7E0F,0x3340,0xFFFC,0x3340,0xFFFC
        .word   0x3340,0xFFFC,0x3340,0xFFFC,0x51CF,0xFFEE,0x22BC,0x4000
        .word   0x0010,0x7E09,0x3340,0xFFFC,0x3340,0xFFFC,0x3340,0xFFFC
        .word   0x3340,0xFFFC,0x51CF,0xFFEE,0x4CDF,0x0381,0x4E75,0x8114
        .word   0x8F01,0x93FF,0x94FF,0x9500,0x9600,0x9780,0x4000,0x0080
        .word   0x8104,0x8F02,0x48E7,0xC140,0x43F9,0x00A1,0x5180,0x08A9
        .word   0x0007,0xFF80,0x66F8,0x3E3C,0x00FF,0x7000,0x7200,0x337C
        .word   0x00FF,0x0004,0x3341,0x0006,0x3340,0x0008,0x4E71,0x0829
        .word   0x0001,0x000B,0x66F8,0x0641,0x0100,0x51CF,0xFFE8,0x4CDF
        .word   0x0283,0x4E75,0x48E7,0x8180,0x41F9,0x00A1,0x5200,0x08A8
        .word   0x0007,0xFF00,0x66F8,0x3E3C,0x001F,0x20C0,0x20C0,0x20C0
        .word   0x20C0,0x51CF,0xFFF6,0x4CDF,0x0181,0x4E75,0x41F9,0x00FF
        .word   0x0000,0x3E3C,0x07FF,0x7000,0x20C0,0x20C0,0x20C0,0x20C0
        .word   0x20C0,0x20C0,0x20C0,0x20C0,0x51CF,0xFFEE,0x3B7C,0x0000
        .word   0x1200,0x7E0A,0x51CF,0xFFFE,0x43F9,0x00A1,0x5100,0x7000
        .word   0x2340,0x0020,0x2340,0x0024,0x1B7C,0x0003,0x5101,0x2E79
        .word   0x0088,0x0000,0x0891,0x0007,0x66FA,0x7000,0x3340,0x0002
        .word   0x3340,0x0004,0x3340,0x0006,0x2340,0x0008,0x2340,0x000C
        .word   0x3340,0x0010,0x3340,0x0030,0x3340,0x0032,0x3340,0x0038
        .word   0x3340,0x0080,0x3340,0x0082,0x08A9,0x0000,0x008B,0x66F8
        .word   0x6100,0xFF12,0x08E9,0x0000,0x008B,0x67F8,0x6100,0xFF06
        .word   0x08A9,0x0000,0x008B,0x6100,0xFF3C,0x303C,0x0040,0x2229
        .word   0x0020,0x0C81,0x5351,0x4552,0x6700,0x0092,0x303C,0x0080
        .word   0x2229,0x0020,0x0C81,0x5344,0x4552,0x6700,0x0080,0x21FC
        .word   0x0088,0x02A2,0x0070,0x303C,0x0002,0x7200,0x122D,0x0001
        .word   0x1429,0x0080,0xE14A,0x8242,0x0801,0x000F,0x660A,0x0801
        .word   0x0006,0x6700,0x0058,0x6008,0x0801,0x0006,0x6600,0x004E
        .word   0x7020,0x41F9,0x0088,0x0000,0x3C28,0x018E,0x4A46,0x6700
        .word   0x0010,0x3429,0x0028,0x0C42,0x0000,0x67F6,0xB446,0x662C
        .word   0x7000,0x2340,0x0028,0x2340,0x002C,0x3E14,0x2C7C,0xFFFF
        .word   0xFFC0,0x4CD6,0x7FF9,0x44FC,0x0000,0x6014,0x43F9,0x00A1
        .word   0x5100,0x3340,0x0006,0x303C,0x8000,0x6004,0x44FC,0x0001

| At this point (0x800), the Work RAM is clear, the VDP initialized, the
| VRAM/VSRAM/CRAM cleared, the Z80 initialized, the 32X initialized,
| both 32X framebuffers cleared, the 32X palette cleared, the SH2s
| checked for a startup error, the adapter TV mode matches the MD TV
| mode, and the ROM checksum checked. If any error is detected, the
| carry is set, otherwise it is cleared. The 68000 main code is now
| entered.

        jmp     __start+0x00880000+0x3F0

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Mon Jan 24, 2011 3:08 am

I just figured you were testing using a 32X image loaded into the ram. If you were just running test code that turned on the 32X and deasserted the SH2 reset, you would DEFINITELY run into this problem. The IP block is from 0x3F0 to 0x7FF and has to match byte-for-byte or it fails. Here's the relevant block I use in Wolf32X
Oh I was testing commercial 32X games that failed due to the timing problems, but my own memory viewer program wasn't working and you were absolutely right about it needing the IP block.

I'm trying to do some 68000-side 32X coding but am having the usual newbie problems, I posted about that in the 32X forum though. :D

User avatar
TmEE co.(TM)
Very interested
Posts: 2357
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Mon Jan 24, 2011 7:53 am

when it comes to making 32X faster you can forget it unless you swap out VRAM chips for 60ns or faster ones. The 80ns ones are at their peaks in 32X, any extra boost is likely to give graphical corruption.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Mon Jan 24, 2011 2:32 pm

TmEE co.(TM) wrote:when it comes to making 32X faster you can forget it unless you swap out VRAM chips for 60ns or faster ones. The 80ns ones are at their peaks in 32X, any extra boost is likely to give graphical corruption.
Wow, I'm surprised it has to be so fast -- thanks for the info!. I am using 55 ns SRAMs, but there's a 25ns delay from CE0# to RAM CS# and then the propagation delay of about 20ns through 74AHCT245s on D0-D15. Replacing the 25ns GAL with a 10ns part gives less corruption but it still isn't much better. I'm not seeing faster transceivers outside of low-voltage specialty parts. :\

I'm also noticing when the adapter is enabled, the LWR# output is not pulsed when writing to the TIME# area. CAS0# and TIME# are otherwise asserted normally for reads.

The manual makes an obscure reference to setting RV=1 before accessing on-cart FRAM/SRAM, but that always freezes the machine and I think that's more about memory at $200000 than the SRAM control at $A130F1.

So with the 32X enabled (just having the IP block) it looks like I can't access the USB or other registers. Are there any 32X games that use the $A130xx range?

Chilly Willy
Very interested
Posts: 2736
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jan 24, 2011 6:28 pm

Charles MacDonald wrote: The manual makes an obscure reference to setting RV=1 before accessing on-cart FRAM/SRAM, but that always freezes the machine and I think that's more about memory at $200000 than the SRAM control at $A130F1.
RV=1 is for MD VDP DMA - the VDP holds off the 68000 and does the DMA all in one block. But in the 32X, the SH2s have priority to the rom over the 68000/VDP, so your DMA is screwed up if the SH2s try to read the rom while DMA is happening. Therefore, the RV bit... when set, the MD memory map is back so that DMA can access the whole rom without banks, and if the SH2s try to access the rom, they are held off until the RV is cleared, which your code does presumably after the DMA is done.

While it is mainly for DMA, the RV bit also helps with SRAM. When you bank switch in the SRAM, the rom in the same area goes away until you switch off the sram. You control the sram from the MD side, so the SH2s don't know what it going on - there is a chance that when you switch out the rom for sram, the SH2s may be using it. So again, RV to the rescue! Set RV before you switch the sram and if the SH2s try to access the rom, they will be held until you are done with the sram and clear the RV bit.

So the RV bit does one thing: halt the SH2s when they try to access rom, but it can be set for two different reasons - DMA and SRAM.

notaz
Very interested
Posts: 191
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Tue Jan 25, 2011 11:35 am

Charles MacDonald wrote:The manual makes an obscure reference to setting RV=1 before accessing on-cart FRAM/SRAM, but that always freezes the machine and I think that's more about memory at $200000 than the SRAM control at $A130F1.
If you are running from 88xxxx do note that this mapping disappears when you set RV, so you start fetching garbage (or don't get DTACK) and crash.
Charles MacDonald wrote: So with the 32X enabled (just having the IP block) it looks like I can't access the USB or other registers. Are there any 32X games that use the $A130xx range?
At least Knuckles Chaotix has SRAM so it is certainly possible. Note that 32x 68k BIOS has some useful routines for this, including code for bank switching:
viewtopic.php?t=611
Don't know why you don't get the LWR pulse though.

User avatar
TmEE co.(TM)
Very interested
Posts: 2357
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Tue Jan 25, 2011 11:58 am

Charles MacDonald wrote:74AHCT245s
Use 74AC245, its much better than HC or HCT and little faster than ACT. You may try F, its very slightly faster than AC, but its TTL not CMOS, but MD is all CMOS so there may be problems with F, but I think they're unlikely to happen.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

User avatar
HardWareMan
Very interested
Posts: 726
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Tue Jan 25, 2011 12:10 pm

I plan to make cards without the ROM. Concept: RAM, CPLD and supervisor with a memory card or PC link. The procedure is the following: when powerup the supervisor fills the primary firmware into RAM and makes nMRES. At rest of time, it handles requests from M68K (memory card or PC link access). Thus, the replacement driver will be simply feed new code via PC link or replace file on memory card. It is possible, I know (and almost done this before). What do you think? I don't like programming that slow FLASHes anymore. :3

Chilly Willy
Very interested
Posts: 2736
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Jan 25, 2011 8:53 pm

notaz wrote: If you are running from 88xxxx do note that this mapping disappears when you set RV, so you start fetching garbage (or don't get DTACK) and crash.
My fault... I forgot that point. RV = 1 switches in the rom down below, but switches OUT the 32X mapping. So you need to be running from ram when you set RV and then use the "old" addresses if you need something from rom.

I wonder if setting RV also switches out the frame buffer and 32X hw... it might be necessary to leave RV = 0 and keep reset asserted to the SH2s to keep all the 32X stuff mapped where the 68k can get it.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Tue Jan 25, 2011 11:43 pm

TmEE co.(TM) wrote: Use 74AC245, its much better than HC or HCT and little faster than ACT. You may try F, its very slightly faster than AC, but its TTL not CMOS, but MD is all CMOS so there may be problems with F, but I think they're unlikely to happen.
I could swear the non-HC/EC 68000's such as those in the Genesis were NMOS and had TTL (LS) compatible I/O. Wasn't the 68HC000 the first CMOS one with HC-compatible Vol/Voh levels? That's why I thought I needed HCT, but maybe that was wrong.

I think removing the buffers would help, but it seems the data and address bus are already heavily loaded with 8 RAMs, 2 flash, and the others. I feel like it would be trading data integrity for speed.

On some other hardware (PC-Engine which is all CMOS, System 18 which has a 68000 like the Genesis) I had problems until I buffered the data bus and then everything worked perfectly. So I'm reluctant to do without it. Hmm, 32X support is harder than I thought!

Also I got the IDE interface working, turns out the compact flash card I was testing with just poorly made. :D

Chilly Willy
Very interested
Posts: 2736
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Jan 26, 2011 12:51 am

It's hard to believe that 10ns delay on the select is causing trouble. If that were the case, it would be nearly impossible to make a 32X flash cart, and both the Everdrive and NeoMyth have no troubles at all with the 32X, despite having slower parts than you've been discussing. It's probably something else in the bus cycle that's not being met... a set up time, or maybe a hold time. Maybe you need a LONGER delay on one of your strobes compared to when you assert the bus enable.

User avatar
Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Wed Jan 26, 2011 2:41 am

Yes it must be something else, considering ROMs were around 100ns back then and these S-RAMS are 55.

I hope I get my holiday soon to do some work on my cart.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Thu Jan 27, 2011 5:45 am

HardWareMan wrote:I plan to make cards without the ROM. Concept: RAM, CPLD and supervisor with a memory card or PC link. The procedure is the following: when powerup the supervisor fills the primary firmware into RAM and makes nMRES. At rest of time, it handles requests from M68K (memory card or PC link access). Thus, the replacement driver will be simply feed new code via PC link or replace file on memory card. It is possible, I know (and almost done this before). What do you think? I don't like programming that slow FLASHes anymore. :3
It sounds like a pretty good idea. For an EPROM emulator project I used the FT2232 in MPSSE mode where it looks like a 8051 bus at the other end of a USB connection and can read/write memory directly but at quite high speeds. This might be one easy way to populate RAM with a 68000 program without needing a boot ROM or a USB-enabled microcontroller on the board.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests