Anything about /TIME

[Jorge Nuno]

But, as you said the I2C is emulated (some implentations only, but thats better than 0 microwire support), so I might go the I2c way

I have just re-read this thread:
http://www.spritesmind.net/_GenDev//for ... .php?t=206

I think I will stick to a 24C02

::Downloading datasheet from ST..::

More than 1Million write/erase cycles!!!

[TmEE co.(TM)]

It's your call.... my mapper is actually a copy protection feature too... at least for a while, I doubt it gets emulated... and if it does I can always change it

[Jorge Nuno]

I'm not worried with copies of my code..., It will be freely distributed maybe with source... but there is a bunch of methods to distiguish emu from real console. Yeah those hardware features are harder, because they are not implemented on the emus

[TmEE co.(TM)]

My favourite is ADDRESS ERROR, as an ASM programmer, every once in a while I MOVE.W #12345, $FF0001... and then when everything works on an emu, then I get nasty ADDRESS ERROR message (with a bang) in my proggy...

Copy protection for COMMERCIAL game... freeware stuff I make doesn't use anything "unique".

[8bitwizard]

And about those I2C/Microwire do the emus support them, is there any official cart with any of those, so it can be compatible with emus?

No released games used Microwire, and no more than 20 or so (including 32X games) used I2C. Many emulators do not support I2C save memory, and even those that do may not support the proper modes (there are three ways to talk to an I2C EEPROM, and all have at least one game that uses them). And then there are at least three different ways that the I2C EEPROMs were interfaced to the 68000 bus. All that in a mere 20 or so games.

When I made my own I2C mapper, I used the code from an existing game as a basis for my own code, which is posted elsewhere on this BB. I even used /TIME for my I/O port just because I could. (and so that I could learn more about /TIME in case someone else wanted to know)

One thing : only emu that supports over 64KB of SRAM is Genecyst. But all need the SRAM needs to be in 200000...20FFFF(3FFFFF on Genecyst) range on any emu that I know of.

As opposed to looking at the RAM info in the cartridge header, which Sega insisted on being correct before having a game (either theirs or third-party) sent to manufacturing? (Yes, I know that some games didn't go through Sega, like most EA and Accolade games.)

I even made sure that my own code has a valid RAM save header and auto-detects save RAM so that it will run properly on an emulator.

[TmEE co.(TM)]

If I put 200000 and 3FFFFF into the cart header, still, only 64KB gets saved, and everything more will be reported illegal write in GensKmod.

[Jorge Nuno]

Many emulators do not support I2C save memory, and even those that do may not support the proper modes (there are three ways to talk to an I2C EEPROM, and all have at least one game that uses them). And then there are at least three different ways that the I2C EEPROMs were interfaced to the 68000 bus. All that in a mere 20 or so games.

How should I do the wiring of SDA/SCL? to be like 1of3 methods?
WriteControl I think I can wire it to ground, because the actual write is a serial command, I think...

And how do I control SCL? only by moves? move 1, move 0, move 1, urghhh this will be very ugly...


How does an emulator recognize an I2C type save? Correct header is enough?

[Eke]

How does an emulator recognize an I2C type save? Correct header is enough?

From the open-source emulators I've seen (I don't know about Kega or Jenesis, which are ones of the few emulators supporting EEPROM saves but are closed source), emulators generally read the header and check the "external RAM" size (sram.end - sram.start). If it is < 2, it is considered as serial eeprom (i.e"custom SRAM"). As most emulators don't emulate these, I guess they simply disactivate SRAM support (ROM area writing is disabled) in this case

Picodrive, for example, is doing like this and emulates mode1/mode2 for some games. It has also some kind of automatic detection for games with bad header (NBA Jam TE) which is activated when the game try to write address 200000h or 200001h (which is generally where EEPROM lines are mapped).

But as 8biwizard said, these methods are not very reliable and would only work with some particualr games. That's why emulators generally only support mode1/mode2 (excepted kega that support mode3, used in College Slam, I think) and common EEPROM mapping (I don't know any emulators that emulate the eeprom present in Rings of Power or Micromachines 2, which use uncommon addresses and bit positions for SDA/SCL).

That's why, the best "detection" method, is definitely to keep an internal game database to know how to emulate each game properly, and I think that's what Kega is doing for example.

[TmEE co.(TM)]

How about expanding MD ROM header ? That's useful only for homebrew stuff though...

[8bitwizard]

How should I do the wiring of SDA/SCL? to be like 1of3 methods?

Look for the other threads on this.

Fom the hardware side you need latches for both SDA and SCL, with the SDA latch controlling the tri-state input of a gate which outputs either a zero or a tri-state (or use an open-collector output), and a pull-up resistor from SDA to VCC.

[Jorge Nuno]

Look for the other threads on this.

I read this one:
http://www.spritesmind.net/_GenDev//for ... .php?t=206

I will be using mode2, the chips I own are ST 24C02/24C04 and they require the 7bit device select after the START command...


Tomorrow I will try to design the schematic, I'm not seeing at the moment how to determine the direction of SDA for those tri-state buffers

Edit: ok flash moment LOL the /C_OE + /LDSW + /UDSW might help me with this..

[8bitwizard]

I used something like this to program my GAL chip:

CLK is the clock input to the SDA/SCL latches

Code: Select all

CLK = !TIME & !WR_L

D7 input from SDA

Code: Select all

D7 = SDA
D7.OE = !TIME & !OE

D6 output to SCL

Code: Select all

SCL := D6 (latched by CLK)

D7 output to SDA

Code: Select all

SDA = 0
SDA.OE := D7 (latched by CLK)

and ROM_CE works just like it always has

Code: Select all

ROM_CE = CE_L

...or find one of the games which uses an I2C EEPROM and trace it out (all use discrete TTL chips except some Accolade games use a mapper chip)