Devcart wishlist?

[Charles MacDonald]

One suggestion - instead of hard coding the address where packing/unpacking/cell-conversion takes place, make that something that can be changed via a register.

Since there's hardly any memory in the system, I was going to have 800000-FFFFFF used for the 1MB RAM where:

A22 enables overwrite
A21 enables pack/unpack
A20 enables cell conversion

So $800000 is normal RAM for code, data, stack, $F00000 has all the fun enabled, etc. I think with the surplus of address registers the 68000 has, this should handle most needs. What do you think?

[Chilly Willy]

0x800000 through 0x9FFFFF is used by the 32X for the frame buffer and MD rom access. 0xA00000 through 0xDFFFFF is reserved for MD IO, and 0xE00000 through 0xFFFFFF is (mirrored) work ram.

That's all on the MD side, of course. I'm not sure if the 32X can access more of the cart on the SH2 side... each space in the 32X is 32MB in size, so as long as accesses to the rom space were fully decoded, a cart could theoretically have 16MB of rom for the SH2. My guess is they used partial decoding with just 4MB being mapped (and probably mirrors over the 32MB range).

So a MD map that accounts for the CD and 32X looks like this:
0x000000 - rom or 32X exception table if 32X enabled or CD stuff if not cart
0x400000 - CD stuff if cart present
0x800000 - 32X stuff
0xA00000 - IO
0xE00000 - work ram

So if you want to work while a CD or 32X is present, you really can't use more than the first 4MB of cart space and the 0xA13xxx space (except for the MARS id location).

That's why I suggested the windows. Make the 4MB range swappable between flash for booting, and ram for running games. When the 4MB is mapped as ram, you can have one or more windows inside that 4MB that has properties like pack/unpack, etc. You would control the mapping and the windows via 0xA13xxx.

[Charles MacDonald]

Sorry, I meant for the coprocessor side. Since the Genesis 68000 is so slow I don't think the nibble stuff and other features would be very useful, or would it?

[KanedaFr]

Two thing I want (the most) about a devcart is the possibility to upload and run the rom without :
- Unplugging the cart.
- Plugging in the computer interface
- Upload the rom
- Unplugging the cart from the computer interface
- Plugging in the MD

+1
and add it with the debug feature

it's all genny dever needs

fyi, for the usb, I was about to use the AT90USB1286 because I dislike the FTDI driver....

[Chilly Willy]

Sorry, I meant for the coprocessor side. Since the Genesis 68000 is so slow I don't think the nibble stuff and other features would be very useful, or would it?

So you meant 0x800000 to 0xFFFFFF on the COPROCESSOR 68000, right? Okay, that would work. It would make the logic easier as well. I was thinking about from the MD side.

As far as COPs go, have you looked at an SH or ARM processor? There are probably models that wouldn't be any more difficult to add than an 68EC000. They would be considerably faster as well, even at the same clock rate. A 20 MHz ARM or SH kicks the shit out of a 20 MHz 68000, taking 1 cycle for most things as opposed to 6 to 10 cycles.

[Charles MacDonald]

As far as COPs go, have you looked at an SH or ARM processor? There are probably models that wouldn't be any more difficult to add than an 68EC000. They would be considerably faster as well, even at the same clock rate. A 20 MHz ARM or SH kicks the shit out of a 20 MHz 68000, taking 1 cycle for most things as opposed to 6 to 10 cycles.

It can be troublesome to interface a 3.3V CPU to a 5V system and all modern ARM and SH chips tend to be that way. In addition they don't have external memory buses unless you get into higher pin counts (e.g. 144 pin TQFP or BGA) which will make assembly difficult. This is the same problem with FPGAs too. Some of the 5V SH-series parts look perfect but are impossible to source for a reasonable price.

I agree the performance of the 68K isn't great, but it seems to be the simplest thing I can interface to the rest of the system without considerable hassle. Since most of the interest here has been for a development tool only, maybe I'll skip the 'extra' features.

[Chilly Willy]

If you skip the coprocessor, then you may want to look at the windows idea again. That could tie into debugging as well - a window (set via A13 regs) could be enabled, overwrite, underwrite, packing, unpacking, write protected, or trapped (generate bus error on access of read/write/instruction fetch).

I looked at available SH processors, and you're looking at $15 to $25 for the older SH2 models that run on 5V; and like you said, the 100 to 112 FP packages are the ones with ext ram/rom buses. Maybe a PIC processor would be better? They even sell those in DIP packages, and it's gotta be more efficient than a 68000.

[Charles MacDonald]

If you skip the coprocessor, then you may want to look at the windows idea again. That could tie into debugging as well - a window (set via A13 regs) could be enabled, overwrite, underwrite, packing, unpacking, write protected, or trapped (generate bus error on access of read/write/instruction fetch).

The window concept, while good, would require a fairly large CPLD or small FPGA which gets back to pin count issues. Unless you wanted large windows with a poor granularity like four 1MB or 512K windows at fixed addresses. And I'm not entirely sure if the Genesis 68000 at 7.67 MHz could push the pixels fast enough.

A 4-bit overwrite mode would help, you'd have to use wait states for the read-modify-write part which means putting it in $800000+, and that kills off the 32X.

Sega did not put the bus error pin on the cartridge connector which sucks for debugging. One Sega devcart had a header to trigger IRQ2 on the Player 2 joystick connector, I suppose that works as long as the software was written to set up and handle IRQ2 interrupts. You could always modify the system to control the bus error pin, but then you'd have this permanently attached wire between the 68000 and the cartridge which could be awkward.

I looked at available SH processors, and you're looking at $15 to $25 for the older SH2 models that run on 5V; and like you said, the 100 to 112 FP packages are the ones with ext ram/rom buses. Maybe a PIC processor would be better? They even sell those in DIP packages, and it's gotta be more efficient than a 68000.

It's a similar story; 3.3V, high pin count, no external memory (the PIC32 chips have an absurd amount of internal memory; 512K Flash and 128K RAM. That's awesome!)

Modern MCUs are so highly integrated that they tend to not have external memory buses because the chip itself has all the I/O, peripherals, RAM, and ROM that you'd ever need. They are great on their own but harder to interface with ancient hardware.

[Charles MacDonald]

and add it with the debug feature

Other than the debug thing I mentioned in the response to Pascal's post, was there any debug features you wanted in particular? Cool things like hardware breakpoints aren't really possible.

fyi, for the usb, I was about to use the AT90USB1286 because I dislike the FTDI driver....

Ah, I was going to use the FTDI driver. Have you had problems with it?

[Alan]

I have used the FTDI chip before, really like it. Never had any problems with their D2XX drivers.
Also the support is very good, couple of times I have sent them emails and got replies within matter of hours.

Regards.

[KanedaFr]

and add it with the debug feature

Other than the debug thing I mentioned in the response to Pascal's post, was there any debug features you wanted in particular? Cool things like hardware breakpoints aren't really possible.

I think about talking with host from the devcart
On GensKMod, I added a fake register to talk with emu
I would like be able to send command from cart to pc
nothing fancy, just bytes like
byte 0: command
byte 1+: data
and to be able to write a program on the host to receipt it

I mainly thing about a log feature (like the Message feature on KMod)
or perhaps talk with KMod...

fyi, for the usb, I was about to use the AT90USB1286 because I dislike the FTDI driver....

Ah, I was going to use the FTDI driver. Have you had problems with it?

1- you need a driver
2- on my PC, there was a conflict with my modem

the ATxxx use standards USB driver and so you could easily create a mouse, a pad, a removal media...anything you want : you "only" need to write a correct USB descriptor and the device software
and, perhaps I'm wrong, you could achieve full speed USB2 on ATxx and not with FTDI

[Alan]

2- on my PC, there was a conflict with my modem
...
you could achieve full speed USB2 on ATxx and not with FTDI

That shouldn't of happened if 'they' used a different VIP/PID, FTDI supply them free of charge to anyone using their chips. However Atmel only give them out to bigger projects, no guarantee you will get one assigned. Of course you could also just find one of the websites that resell their PID values. It's not allowed by the USB-IF but there isn't much that can be done about it, even if they was to reject the VID it cant be reassigned as it may cause conflicts.

FTDI both have high speed and full speed chips, just depends how much willing to pocket with.

If you are able to make your device work within the HID class spec then I guess that would be the way to go, don't have to worry about drivers. Main advantage of using the AT90 is that you get all the features of a AVR microcontroller as well. Might be able to offload some work onto that, were as if using the FTDI chip you still need something to interface it with.

[Charles MacDonald]

In this case the throughput will always be limited by the Genesis 68000, so data rates will have an upper limit. In practice it's fast enough; on the PC-Engine I could upload and run a 512K game in a matter of seconds and it is slower than the 68000.

But I wonder about switching chips. I like the FT245/FT2232 because it looks like a peripheral to the host CPU, and you just read and write it to get and send data.

I've had a lingering bug where reading data sometimes fails which normally isn't an issue as you spend most time uploading data. But in a recent project I think I've finally cornered the bug and may be able to finally get a reproducible test case I can write to FTDI about. I've heard similar complaints from other projects so I don't think it's just me.

Maybe both channels of the FT2232 would work, with one port for output and the other for input. That's assuming this problem manifests itself for mixed reads/writes (I suspect it might).

I've been using FTDI chips since 2004 and really cannot complain, but if there's something better out there that's appropriate for this project (5V compatible I/O, suitable for a host processor), I'll use it.

That said, what would make a good replacement? All the USB-enabled microcontrollers aren't really designed to interface with a host processor; this means you'd need some kind of handshaking between the two would slow things down. I think some chips like a PIC have a 8255-like parallel port with limited handshaking but most discussions of it are about the problems rather than the successes. There are very few USB products that are designed to be a peripheral for a microprocessor.

Now there are such peripherals for Ethernet, but that sounds like serious overkill in terms of functionality and cost. It would be kind of fun to have the Genesis remotely access files on a PC through a router when browsing for a game to play, or put the console on the Internet.

EDIT:

Cheaper than I thought:

http://www.sparkfun.com/commerce/produc ... ts_id=9473
Would need additional parts for 5V<->3.3V level shifting.

http://www.sparkfun.com/commerce/produc ... cts_id=200
More expensive but 5V friendly.

The FT245 and FT2232 modules are $25 and $35 so these are exactly equivalent. Now I think SparkFun has terrible quality on their breakout boards but there are no major complaints from users of these parts that I know of.

Not as convenient as USB, but it's just another option I guess.

[HardWareMan]

I gave up on USB. Now I use the LAN. See for yourself. I bought the unit for $12.


Benefits?
1. Distance. 1 meter or 100 (within the local segment) or on the other end of the earth - not important! Someone make device (who really can do this) and all of rest can use this device.
2. Galvanic isolation.
3. Independence from the operating system!
4. Transfer speed up to 10MBytes/s at peak (100Mbps LAN, depend on channels speed of route for far distance connection)!
5. ....
6. PROFIT!
If you use the WiFi module (a little expensive), there is no wires. Your opinion?

[Chilly Willy]

Ethernet is good. Gives you a chance to even make a web server out of the Genesis. Think it's crazy? People have made web servers from the C64 using Contiki OS. A Genesis with a cart that has 4MB of ram, a CF interface, and an ethernet port would be far better than that.