Migrating Genesis core to FX68K

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3158
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: FX68K Cycle accurate 68000 core

Postby Sorgelig » Wed Nov 14, 2018 3:03 pm

Should reset be released before specific enPhi1/2 or doesn't matter?

OzOnE
Atarian
Atarian
Posts: 7
Joined: Mon Oct 22, 2018 5:28 pm

Re: FX68K Cycle accurate 68000 core

Postby OzOnE » Wed Nov 14, 2018 4:02 pm

That's a good question. I'm currently trying to get it running on the latest Genesis core as well.

Quartus doesn't seem to like generating a Verilog Instantiation template nor VHDL Component Declaration file when there are "structs" in the code, so I had to manually add that.

And I had the usual annoyances with VHDL, where I had to add the Comp Declaration as well, and various other issues.

And then I saw that Sorgelig had changed the Genesis top level to Verilog a few days ago anyway. LOL :p

What I've done so far is to use "reset" for both of the reset inputs, then tied the enPHI signals both High, and used TG68K_ENA along with the main MCLK, which is probably completely the wrong thing to do, but I'm just messing atm.

I realise that the older TG68K core also didn't have a direct AS_N output, so I've changed the reg for that to a wire, then commented out lines 131 and 137 in Genesis.v (which was originally toggling TG68_AS_N as a reg).

But then I saw that TG68_STATE obviously isn't part of FX68K either, and that was being used to keep TG68_ENA_DIV in sync. So, I'd better leave it to you guys to figure that out, as I'm a bit stuck now.

And yep, as expected, tying the PHI enabled high, then ANDing TG68K_ENA with MCLK doesn't seem to work either.

Should VPAn be tied High on the Genesis core as well? That's only for 6800 mode, right?

I've tied these all High atm...

.VPAn(1'b1),
.BERRn(1'b1),
.BRn(1'b1),
.BGACKn(1'b1),

I'm not seeing any activity at all on eab (address output) on SignalTap, it just stays low all the time.

FX68K is being brought out of reset by MiSTer now, it seems, and is toggling between Tstate T0 and T4?

I'm guessing it's because I've screwed up the PHI / clock enables? lol

Anyway, yeah, I'll leave it to you guys now.

OzOnE / ElectronAsh.

OzOnE
Atarian
Atarian
Posts: 7
Joined: Mon Oct 22, 2018 5:28 pm

Re: FX68K Cycle accurate 68000 core

Postby OzOnE » Wed Nov 14, 2018 4:59 pm

OK, I see now that the PHI1 and PHI2 signals need to be generated.

I've tried adding a 3-bit clock divider, then just asserting PHI1 on 0 and PHI2 on 4...

https://i.imgur.com/rGp7wq6.png

I suspect I've messed up the logic for the clock div in the Genesis.v now, since it no longer has TG68K_STATE for this...

// keep counter at 0 in non-bus cycles.
if (TG68_STATE == 1) TG68_ENA_DIV <= 0;

How close together can the PHI1 and PHI2 pulses be? Can they just be asserted on each alternate clk edge?

Any reason why those can't be generated within the FX68K core itself?
I mean, it's not a huge deal, but would it be possible to have only the original 68000 signals exposed?

(I see there's a note about needing a clock twice as high for the core as well, which is fine. I'm assuming that means that PHI1 and PHI2 can be directly next to each other in that case?)

I would post a few more updates, but the forum is REALLY slow right now. It took me ten minutes to get my first reply to work. lol

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: FX68K Cycle accurate 68000 core

Postby ijor » Wed Nov 14, 2018 5:05 pm

Sorgelig wrote:can you release it on github? Then there will be a central development repo for this IP, so you can get some pull requests if you don't mind.


Sure, no problem. But give me please a couple of days.

Should reset be released before specific enPhi1/2 or doesn't matter?


Shouldn't matter.

I am probably stating the obvious, but if you are migrating from TG68K (as I guess you are), you must take are of all the details of the 68000 bus interface that TG68K simplifies. Most signals are not active during the whole bus cycle, but only on specific cycles and phases. And the processor expects DTACK (or BERR, or VPA) to be asserted no later than a specific state, or it will generate wait states.

For those that are not very familiar with the 68000 bus operation, please see section 5 of the user manual: https://www.nxp.com/docs/en/reference-m ... 8000UM.pdf

OzOnE wrote:Should VPAn be tied High on the Genesis core as well? That's only for 6800 mode, right?


I understand that the Genesis does use VPAn. Not sure how and when. May be for interrupts only because it VPAn activates autovector interrupt?

FX68K is being brought out of reset by MiSTer now, it seems, and is toggling between Tstate T0 and T4? ...
I'm guessing it's because I've screwed up the PHI / clock enables? lol ...
then tied the enPHI signals both High


That won't work. See the sample at the end of main source file for how to generate correct enPhi1 and enPhi2 signals.

Edit: Fixed typo that missed the word "WAIT" in wait states.
Fx Cast: Atari St cycle accurate fpga core

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: FX68K Cycle accurate 68000 core

Postby ijor » Wed Nov 14, 2018 5:19 pm

OzOnE wrote:How close together can the PHI1 and PHI2 pulses be? Can they just be asserted on each alternate clk edge?
Any reason why those can't be generated within the FX68K core itself?
I mean, it's not a huge deal, but would it be possible to have only the original 68000 signals exposed?
(I see there's a note about needing a clock twice as high for the core as well, which is fine. I'm assuming that means that PHI1 and PHI2 can be directly next to each other in that case?)


Yes. They can be active one right after the after, which would be the natural thing for do if the clock is exactly 2x.

The reason I am using a 2x clock is because otherwise it would need async logic for those signals that change on both edges of the clock. That was fine on the old school days. But it is against modern synchronous design practice, especially for FPGA logic.

Once you require a 2x clock, then it is much better to allow any faster clock, and not just only exactly a 2x one. So the CPU have no idea about the relation between the real and the nominal clock. That's the purpose of the clock enable signals. And they might need to be in sync with external signals, so they can't be generated internally by the CPU core.

Using a 2x clock is also better for following the same exact timing as the original CPU. As was common at the time, the original implementation uses transparent latches, not edge triggered flip flops. Those latches are controlled by a single phase of the clock. So using a 2x allows a direct translation between a clock phase (PHI1 or PHI2) and a clock cycle edge.
Fx Cast: Atari St cycle accurate fpga core

OzOnE
Atarian
Atarian
Posts: 7
Joined: Mon Oct 22, 2018 5:28 pm

Re: FX68K Cycle accurate 68000 core

Postby OzOnE » Wed Nov 14, 2018 5:32 pm

Thanks for your replies.

(I tried to post this earlier, but the forum is still very broken.)...


This is where it gets to with asserting PHI1 on 0 and PHI2 on 4 (with a 3-bit clock divider).

https://i.imgur.com/rGp7wq6.png

I suspect I've messed up the logic for the clock div in the Genesis.v now, since it no longer has TG68K_STATE for this...

// keep counter at 0 in non-bus cycles.
if (TG68_STATE == 1) TG68_ENA_DIV <= 0;


I would post a few more updates, but the forum is REALLY slow right now. It took me ten minutes to get my first reply to work. lol


Actually, the Genesis core doesn't appear to use VPA_N atm, at least not externally to TG68K?...

Code: Select all

TG68KdotC_Kernel #(.TASbug(1)) CPU_68K
(
   .clk(MCLK),
   .nreset(~reset),
   .clkena_in(TG68_ENA),
   .data_in(TG68_DI),
   .ipl(TG68_IPL_N),
   .addr(TG68_A),
   .data_write(TG68_DO),
   .nuds(TG68_UDS_N),
   .nlds(TG68_LDS_N),
   .nwr(TG68_RNW),
   .busstate(TG68_STATE),
   .fc(TG68_FC)
);


Obviously busstate is the only thing that's really "missing", but it seems like it was purely being used to synchronize their clock divider, and generated AS_N.

I'll try pulsing PHI1 and PHI2 on alternate MCLKs next, and try adding the proper clock enable from the Genesis core. ;)

It is at least trying to work now. I just need to see what's stopping it booting the cart ROM.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3158
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: FX68K Cycle accurate 68000 core

Postby Sorgelig » Wed Nov 14, 2018 6:19 pm

ijor wrote:I am probably stating the obvious, but if you are migrating from TG68K (as I guess you are), you must take are of all the details of the 68000 bus interface that TG68K simplifies. Most signals are not active during the whole bus cycle, but only on specific cycles and phases. And the processor expects DTACK (or BERR, or VPA) to be asserted no later than a specific state, or it will generate bus states.

not obvious.. According to manual, there is no limit when DTACK can be asserted. CPU should insert wait states till DTACK will be asserted. At least i couldn't find opposite in manual. In Genesis core DTACK is used for holding CPU.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: FX68K Cycle accurate 68000 core

Postby ijor » Wed Nov 14, 2018 8:28 pm

Sorgelig wrote:
ijor wrote:I am probably stating the obvious, but if you are migrating from TG68K (as I guess you are), you must take are of all the details of the 68000 bus interface that TG68K simplifies. Most signals are not active during the whole bus cycle, but only on specific cycles and phases. And the processor expects DTACK (or BERR, or VPA) to be asserted no later than a specific state, or it will generate bus states.

not obvious.. According to manual, there is no limit when DTACK can be asserted. CPU should insert wait states till DTACK will be asserted. At least i couldn't find opposite in manual. In Genesis core DTACK is used for holding CPU.


Yes, exactly. I didn't express myself correctly (I made a typo there and missed the "wait"). The CPU will wait as much as you like if you don't assert DTACK. What I meant is that it should be asserted early enough if you DON'T want to generate wait states. And that is no later than a specific phase of the bus cycle (S4). Not sure this is required by TG68K, might be TG68K can accept DTACK at a slightly later phase without generating wait states (say, S6 or S7); that's why I'm raising the issue.
Fx Cast: Atari St cycle accurate fpga core

fpgaarcade
Atari freak
Atari freak
Posts: 67
Joined: Thu Sep 20, 2007 10:06 pm
Location: Sweden

Re: FX68K Cycle accurate 68000 core

Postby fpgaarcade » Wed Nov 14, 2018 8:49 pm

I'm still sorting out my github stuff, but here is my fx68k wrapper if it helps.
/MikeJ
replay_cpu_fx68k.txt
You do not have the required permissions to view the files attached to this post.

fpgaarcade
Atari freak
Atari freak
Posts: 67
Joined: Thu Sep 20, 2007 10:06 pm
Location: Sweden

Re: FX68K Cycle accurate 68000 core

Postby fpgaarcade » Wed Nov 14, 2018 8:50 pm

note, I modified the top to bring out the PHI enables directly. I had to use a different synthesis tool as the old Xilinx software does not support SV

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: FX68K Cycle accurate 68000 core

Postby ijor » Wed Nov 14, 2018 8:52 pm

OzOnE wrote:https://i.imgur.com/rGp7wq6.png
This is where it gets to with asserting PHI1 on 0 and PHI2 on 4 (with a 3-bit clock divider).


Not sure if that's what you want, but seems you are dividing the clock by 8. I see 8 cycles between each PHI1 pulses.

I also see that DTACK is deasserted too late, well when the next bus cycle already started. I can't say for sure, without double checking, if that is harmless or not, but that is certainly against the official specifications. Is that deasserted that late on the original Genesis hardware?

Actually, the Genesis core doesn't appear to use VPA_N atm, at least not externally to TG68K?...


May be it should. I can see VPA is connected on the Genesis schematics I found online. Not saying that this is your main problem right now. But I seem to remember that TG68K originally didn't have the 6800 signals (VPA,E,VMA) because the Amiga don't use them. So may be VPA is connected to some logic external to the CPU instead?

It is at least trying to work now. I just need to see what's stopping it booting the cart ROM.


Seems the CPU is trying to boot from address $206 and it reads opcode $4AB9 from that address. Is that correct?

Can you show me a write cycle. May be there is a problem there.

Also note that Signal Tap II can understand and display machine states in a single line if you prefer. There is no need to tap the individual states (tState.tX) separately.
Fx Cast: Atari St cycle accurate fpga core

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: FX68K Cycle accurate 68000 core

Postby ijor » Wed Nov 14, 2018 8:53 pm

fpgaarcade wrote:note, I modified the top to bring out the PHI enables directly. I had to use a different synthesis tool as the old Xilinx software does not support SV


Hi Mike. Please check the download as it is slightly modified in relation to what you had. I'm not using a struct as an external port anymore.
Fx Cast: Atari St cycle accurate fpga core

fpgaarcade
Atari freak
Atari freak
Posts: 67
Joined: Thu Sep 20, 2007 10:06 pm
Location: Sweden

Re: FX68K Cycle accurate 68000 core

Postby fpgaarcade » Wed Nov 14, 2018 9:07 pm

Yup, updated thanks.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Migrating Genesis core to FX68K

Postby ijor » Thu Nov 15, 2018 1:48 am

This thread is a split from this one: viewtopic.php?f=28&t=34730

I know the subject is not really exclusive to MiSTer, but I thought this would be the best place. I can still move it somewhere else if needed.
Fx Cast: Atari St cycle accurate fpga core

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: FX68K Cycle accurate 68000 core

Postby ijor » Thu Nov 15, 2018 2:20 am

Sorgelig wrote:In Genesis core DTACK is used for holding CPU.


Anybody made some traces with a logic analyzer on real Genesis hardware showing the clocks and the bus control signals? That could be very useful.
Fx Cast: Atari St cycle accurate fpga core

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3158
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Migrating Genesis core to FX68K

Postby Sorgelig » Thu Nov 15, 2018 5:33 am

Well, in Genesis core DTACK is released at the next clock cycle (i mean cycle of 54MHz, not CE cycle) after CPU releases the TG68_IO = ~TG68_AS_N & (~TG68_UDS_N | ~TG68_LDS_N). So, CPU won't see DTACK on its next CE cycle.

slingshot
Captain Atari
Captain Atari
Posts: 349
Joined: Mon Aug 06, 2018 3:05 pm

Re: FX68K Cycle accurate 68000 core

Postby slingshot » Thu Nov 15, 2018 10:03 am

OzOnE wrote:Should VPAn be tied High on the Genesis core as well? That's only for 6800 mode, right?


I understand that the Genesis does use VPAn. Not sure how and when. May be for interrupts only because it VPAn activates autovector interrupt?


In the service manual, only VPAn is connected (as it needed for auto-vectoring), VMA and E are not at all. Just have to figure out, when it should put to low, probably together with IPL lines, since you cannot know when the VDP will raise an interrupt.

slingshot
Captain Atari
Captain Atari
Posts: 349
Joined: Mon Aug 06, 2018 3:05 pm

Re: FX68K Cycle accurate 68000 core

Postby slingshot » Thu Nov 15, 2018 10:19 am

ijor wrote:Yes, exactly. I didn't express myself correctly (I made a typo there and missed the "wait"). The CPU will wait as much as you like if you don't assert DTACK. What I meant is that it should be asserted early enough if you DON'T want to generate wait states. And that is no later than a specific phase of the bus cycle (S4). Not sure this is required by TG68K, might be TG68K can accept DTACK at a slightly later phase without generating wait states (say, S6 or S7); that's why I'm raising the issue.


I wonder how important in the Genesis core to be aware of the current bus state. The original peripherals (RAM, ROM, VDP, etc...) don't know about them too much, probably just watch ASn and if it's asserted, then they know there's something to do. Also it's up to the peripheral to assert DTACK_N, if it's slower, and miss the accepting state, then you cannot do much about it.
Upd.: realized that uds_n and lds_n are asserted after ASn, so some knowledge is must about cycles...ahh that complicates things.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Migrating Genesis core to FX68K

Postby ijor » Thu Nov 15, 2018 7:58 pm

Will try to help integrating FX68K with the Genesis core. I would need first to familiarize myself with the core, and also with the Genesis hardware.

But there doesn't seem to be much information about the arbiter. What's the timing of DTACK (how many wait states are inserted)? How DMA is implemented? When the arbiter request the bus? Only when the Z80 requests the bus, or there are some other DMA agents?

slingshot wrote:In the service manual, only VPAn is connected (as it needed for auto-vectoring), VMA and E are not at all. Just have to figure out, when it should put to low, probably together with IPL lines, since you cannot know when the VDP will raise an interrupt.


Yes, I can see that only VPAn is connected. So probably it's only used for interrupt auto vectoring. But do all interrupts use autovectoring? Or some do and some don't?

The original peripherals (RAM, ROM, VDP, etc...) don't know about them too much, probably just watch ASn and if it's asserted, then they know there's something to do.
...
Upd.: realized that uds_n and lds_n are asserted after ASn, so some knowledge is must about cycles...ahh that complicates things.


ASn is typically used by the chip select logic only, which in this case I assume it is the arbiter. Peripherals normally watch only for the DS signals and a specific chip select control. They normally are not connected to ASn at all.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Captain Atari
Captain Atari
Posts: 349
Joined: Mon Aug 06, 2018 3:05 pm

Re: Migrating Genesis core to FX68K

Postby slingshot » Thu Nov 15, 2018 8:33 pm

ijor wrote:Will try to help integrating FX68K with the Genesis core. I would need first to familiarize myself with the core, and also with the Genesis hardware.

Would be awesome, thank you!

But there doesn't seem to be much information about the arbiter. What's the timing of DTACK (how many wait states are inserted)? How DMA is implemented? When the arbiter request the bus? Only when the Z80 requests the bus, or there are some other DMA agents?

There's a DMA which can be initiated by the VDP, now it's only uses DTACK to hold the CPU. Probably the original way is to request the bus before the transfer.
The current implementation for other access asserts DTACK_N ASAP, it's ok for now. Probably RAM and ROM delay can be implemented later on, but that's not that important for games (The Titan 2 demo seems to use it for some extent).

slingshot wrote:In the service manual, only VPAn is connected (as it needed for auto-vectoring), VMA and E are not at all. Just have to figure out, when it should put to low, probably together with IPL lines, since you cannot know when the VDP will raise an interrupt.


Yes, I can see that only VPAn is connected. So probably it's only used for interrupt auto vectoring. But do all interrupts use autovectoring? Or some do and some don't?

There are only 2 interrupts, horizontal and vertical from the VDP, level 4 and level 6, with auto-vectoring. There's an external one on the hardware, but that's also auto-vectored, and not implemented here (used by light-guns mostly).

ASn is typically used by the chip select logic only, which in this case I assume it is the arbiter. Peripherals normally watch only for the DS signals and a specific chip select control. They normally are not connected to ASn at all.


I see it's connected on the schematic (but the bus arbiter is a black box, don't know what it does), but good idea to watch only L|UDS, makes things easier.

Upd.: Ignoring ASn did the trick, some ROMs are now working. The VDPFifoTestROM wait states tests passed, this means timing are much better than with TG68k. ROMs with interrupts seems to not work yet.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Migrating Genesis core to FX68K

Postby ijor » Thu Nov 15, 2018 9:54 pm

slingshot wrote:There's a DMA which can be initiated by the VDP, now it's only uses DTACK to hold the CPU. Probably the original way is to request the bus before the transfer.


Yes, DTACK can't work on real hardware because the CPU will wait but it won't relinquish the bus. And this also applies when the Z80 uses the bus. At the FPGA core we don't care. We don't really have a shared bus. But the timing would be different if we keep using DTACK. If we want accurate timing we need to implement a DMA request state machine at the arbiter logic. I wonder if it's really worth, because without knowing the arbiter internal timing, it won't be accurate anyway.

(but the bus arbiter is a black box, don't know what it does)


I see, but nobody performed some kind of reverse engineer? Are software emulators accurate? Do they run the Titan 2 demo? If so that would mean that there should be some knowledge there.

but good idea to watch only L|UDS, makes things easier.


I didn't mean exactly that. I meant that the peripherals don't watch, and probably don't see ASn. But ASn is still very relevant for the arbiter.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Captain Atari
Captain Atari
Posts: 349
Joined: Mon Aug 06, 2018 3:05 pm

Re: Migrating Genesis core to FX68K

Postby slingshot » Thu Nov 15, 2018 10:23 pm

ijor wrote:I see, but nobody performed some kind of reverse engineer? Are software emulators accurate? Do they run the Titan 2 demo? If so that would mean that there should be some knowledge there.


Must be investigated, I don't see it as so critical. Without the correct CPU, it didn't matter. Now probably can be fine-tuned.
but good idea to watch only L|UDS, makes things easier.


I didn't mean exactly that. I meant that the peripherals don't watch, and probably don't see ASn. But ASn is still very relevant for the arbiter.


Seems to work with ignoring ASn :)
And from the manual, I've assert VPAn in INTACK, fixed the interrupts! Genesis core works with FX68K now! Titan2 demo is more perfect than before.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3158
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Migrating Genesis core to FX68K

Postby Sorgelig » Fri Nov 16, 2018 12:17 am

Yeah, migrating is done. It works.
Now need to tweak some signals and timings.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Migrating Genesis core to FX68K

Postby ijor » Fri Nov 16, 2018 12:34 am

slingshot wrote:And from the manual, I've assert VPAn in INTACK, fixed the interrupts! Genesis core works with FX68K now! Titan2 demo is more perfect than before.


Sorgelig wrote:Yeah, migrating is done. It works.
Now need to tweak some signals and timings.


Great! But where it is? I am probably missing something, but I can't find it on github
Fx Cast: Atari St cycle accurate fpga core

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3158
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Migrating Genesis core to FX68K

Postby Sorgelig » Fri Nov 16, 2018 6:10 am

i didn't push to github yet. still need to fix something


Return to “MiSTer”

Who is online

Users browsing this forum: No registered users and 5 guests