68000 boot code

[billt]

Hey Mods, someone suggested I post here and gave a link to this particular forum. Please move to Coders. Asm / Hardware as that seems to make more sense.

I'm interested in doing some minimal boot code for 68000. The goal is to simulate a softcore 68000 such as tg68 or wf68k00 and look at bus cycles in waveform viewer. So i need to be able to see a few reads and a few writes, doing more later on. I assume that assembly is best approach for this as there is no os or kickstart or anything at all to run, and i want very detailed control of what happens when. But i have not done assembly since 1994 and that was using vax toolchain at university. What should I use in AmigaOS (WinUEA) or windows or linux to accomplish executable from assembly? And where do I go to see good assembly examples? In the past year Ive done minimal Rabbit3000 and PicoBlaze assembly, which I do not recognize from old 68000 class so long ago.

Thank you for your help!

(I do software running cpu simulations at work on Arm chips from C test code, but this has bit boot rom code underneath, this 68000 sim will be a lot different)

[robinsonb5]

Funnily enough I'm playing around with almost exactly this kind of thing at the moment. I've got an Altera DE1 board and I've got the 68020-compatible version of TG68 running on the FPGA, reading a simple program.

Note that the TG68's bus interface is slightly different from the "real" 68000 - and instead of using /DTACK there's a CLKENA signal that you simply hold low until data is ready. (The Minimig ports that use TG68 have a wrapper that translates to more traditional 68K signals.)

For assembling simple test programs I use EASy68k which has a simulator/debugger and can generate listings and S-records.

Tonight I'm experimenting with SDRAM, and have a simple VGA framebuffer running, filled with the TG68.

I plan to put details (and project code) on the site in my sig in due course - but in the meantime if you'd like to take a look, the very first baby steps can be found, as a QuartusII project, here. This project runs a very simple program on the TG68 which increments a counter and writes the result to the 4-digit hex display on the DE1 board. If you'd like the latest version just PM me to remind me and I'll zip it up at some point.

[billt]

Originally Posted by robinsonb5

Funnily enough I'm playing around with almost exactly this kind of thing at the moment. I've got an Altera DE1 board and I've got the 68020-compatible version of TG68 running on the FPGA, reading a simple program.

Note that the TG68's bus interface is slightly different from the "real" 68000 - and instead of using /DTACK there's a CLKENA signal that you simply hold low until data is ready. (The Minimig ports that use TG68 have a wrapper that translates to more traditional 68K signals.)

For assembling simple test programs I use EASy68k which has a simulator/debugger and can generate listings and S-records.

Tonight I'm experimenting with SDRAM, and have a simple VGA framebuffer running, filled with the TG68.

I plan to put details (and project code) on the site in my sig in due course - but in the meantime if you'd like to take a look, the very first baby steps can be found, as a QuartusII project, here. This project runs a very simple program on the TG68 which increments a counter and writes the result to the 4-digit hex display on the DE1 board. If you'd like the latest version just PM me to remind me and I'll zip it up at some point.

wow, cool. i'm about to start playing with a vga port for university project using nexys2/xilinx. this fall i plan to take fpga/soc course. i'm really interested in playing with minimig, aoocs and suska. i have a de1 around here somewhere too, as well as spartan3 on a pci card for fun things.

[robinsonb5]

For anyone who's interested, I've now got my simple test project working using the TG68K + wrapper, rather than using the TG68K bare, so it's now using traditional MC68000 signals.
http://retroramblings.net/?p=59

[robinsonb5]

Originally Posted by billt

wow, cool. i'm about to start playing with a vga port for university project using nexys2/xilinx.

That should be a lot of fun

this fall i plan to take fpga/soc course. i'm really interested in playing with minimig, aoocs and suska. i have a de1 around here somewhere too, as well as spartan3 on a pci card for fun things.

I love the DE1 board - not had a chance to play with a Spartan yet though. Coming to FPGAs from a C++ background I'm certainly finding the parallelism of operations on an FPGA a new and unfamiliar way of programming!

[billt]

from your blog page:

(Note that the longword at location 0 is the initial Stack Pointer, and at location 4 is the initial Program Counter, so we start the actual program at location 8.)

Interesting. I was trying to figure out what to use for the address of the first instruction, and from the Freescale docs had concluded I should org to $0004. I haven't been able to find much about the whole reset vector thing, it took some searching to find that reset puts PC to $0004. So now I'm confused, why do you not org to $0004? What exists at $0004? Why shouldn't I start there? Does PC actually execute the $0004 thing on reset, or is the very first thing that happens after reset is released is PC doing an increment and landing at $0008 for the first thing to read, parse, and execute?

Man, it's been ages since I've done 68000, 1994 or 1995... And back then we had a boot ROM thingamy in place for loading the board from a terminal. I'm going to have to dig out my books from that class, as some of these particular details seem to be hard to find now.

[billt]

Originally Posted by robinsonb5

That should be a lot of fun

I love the DE1 board - not had a chance to play with a Spartan yet though. Coming to FPGAs from a C++ background I'm certainly finding the parallelism of operations on an FPGA a new and unfamiliar way of programming!

I got a very minimal display up on my monitor the other day. Nothing exciting to look at, you had a choice of solid red or solid green. Red was 800x600@72Hz and green was 640x480@60Hz. But it's up, and now I am workign on the state machine to decide what color each pixel should be to draw the game we're doing. (No framebuffer, no processor, no software) I'm going to be very happy when this is over, it's burning me out quick... But it's really cool to learn how to do this stuff!

It took quite a while to "get it" for HDL coding. (Verilog or VHDL, for me it was Verilog for until this VHDL class started in January) A couple years ago, after spending a decade wading around in Verilog gates netlists (for ASIC LVS verification, the ASIC design in question being an FPGA chip) and after a while also wading around in Verilog RTL written by other people, I finally got an opportunity to try my first RTL in Verilog. I then learned that you don't set your initial values of registers with an initial block, and what the right way to do that sort of thing was. (All I'd cone before was simulations) Then other things started to make more sense. And this VHDL design class very quickly got me thinking much better about how to woth with an HDL language for making something go into an FPGA and work. And some of my old ideas back when I didn't know enough to get anywhere are popping back into my head again, along with a couple new ones, some involving the standard 680x0 busses.

At a few meetings some coworkers would occasionally mention that they were trying to do their code to do a certain hardware style, and I had no idea how synthesizers work and couldn't do that imagination myself. Eventually it soaked in and began to make sense, and now I feel much more like I'm typing a netlist (RTL abstracted of course) And and operation is not like a C instruction to fetch, load, operate and store. It's an AND gate. Maybe a few AND gates in parallel for a multibit thing. An if/else or a case is a multiplexer. And that's a gate too, or a number of gates in parallel. And being able to think of things as gates rather than instructions helped me get a lot more comfortable with the completely parallel nature of RTL code.

[billt]

http://www.easy68k.com/EASy68Kforum/...b0e26479e663fc

What happens is that the longword at $00000000 is loaded into ths stack pointer (a7) and the longword at $00000004 is loaded into the program counter and the processor starts executing code from that address.

That guy makes it sound, for your simple counter program, that the value $00000008 should be stored in the longword at $0004, as the PC ls loaded with the value at $0004, it doesn't point to $0004. If this guy is right, then you're loading PC with who knows what value that happens to be at $0004. Do I not understand something correctly?

[robinsonb5]

Originally Posted by billt

That guy makes it sound, for your simple counter program, that the value $00000008 should be stored in the longword at $0004, as the PC ls loaded with the value at $0004, it doesn't point to $0004. If this guy is right, then you're loading PC with who knows what value that happens to be at $0004. Do I not understand something correctly?

You're absolutely correct - but if you look at the VHDL code, you'll see that for the word read at 0x0006, I return "0008", and all uncoded address return "0000" - thus the longword read from 0 sets the stack pointer to 0, and the longword read from 4 sets the initial program counter to 8. The only reason I didn't include those two words in the assembly listing is that I didn't need the assembler to do that bit!

What I probably should have done instead is:
org 0x00
dc.l 0
dc.l 8
Start:
...
In fact since that's much clearer, I'll go edit the post now - thanks for the feedback

I got a very minimal display up on my monitor the other day. Nothing exciting to look at, you had a choice of solid red or solid green. Red was 800x600@72Hz and green was 640x480@60Hz. But it's up, and now I am workign on the state machine to decide what color each pixel should be to draw the game we're doing. (No framebuffer, no processor, no software) I'm going to be very happy when this is over, it's burning me out quick... But it's really cool to learn how to do this stuff!

Yeah it's very satisfying once you get it working. I wrote a simple "Pong" game for the Turbo Chameleon a couple of months back (using the hwtest program as a skeleton, so I didn't have to start from scratch with PS/2 mouse comms and VGA out), and I found myself using the current pixel position almost like a "program counter" to keep events happening in the right sequence! Writing programs to run sequentially is a hard habit to break!

[Photon]

Is this related to Amiga hardware or OS? Other than selecting (a good) one of many emulators that do 68000, I mean. Just not sure if we yet have a forum that fits that I could move it to.

You can use AsmOne and assemble "in" the emulator but a few use their favorite PC text editor and launch any UAE to run it. You couldn't really ORG $4 and expect to pop back in the assembler when your code has run if you code in an Amiga assembler, you'd have to cold reset the Amiga/emulation.

If my intuition is right, Linux will have some mature packages.

[robinsonb5]

Originally Posted by Photon

Is this related to Amiga hardware or OS?

Good question. In my case I'm doing this stuff to gain a better understanding of the Minimig core, and hopefully thereafter to work on improving the DE1 and Chameleon ports. Beyond that I guess the biggest Amiga relevance is simply that an Amiga forum is a good place to find people with 68000 expertise!

[billt]

Originally Posted by Photon

Is this related to Amiga hardware or OS? Other than selecting (a good) one of many emulators that do 68000, I mean. Just not sure if we yet have a forum that fits that I could move it to.

It's ultimately a question about 68000 assembly language programming and compilers, perhaps such as what I could use in WinUAE/OS3.9. The target "system" to run said 680x0 compiled binary on I'm not calling relevant, and I wouldn't expect what I want to do to be very useful running "on" the emulated Amiga directly or on classic hardware. It will be as little code as possible to cause certain bus cycles to happen, and I'd have to make a kickstart image of my otherwise useless code, which I'm not inclined to bother doing.

You can use AsmOne and assemble "in" the emulator but a few use their favorite PC text editor and launch any UAE to run it. You couldn't really ORG $4 and expect to pop back in the assembler when your code has run if you code in an Amiga assembler, you'd have to cold reset the Amiga/emulation.

If my intuition is right, Linux will have some mature packages.

Maybe someone needs to port a fuller 68000 simulator like Easy68k to AmigaOS then, so we have more than just the compiler/assembler. I'll try to have a look at AsmOne when I get a chance.

My interest is Amiga hardware, in the sense that Minimig is and that an FPGA can pretend to be a 68000 or something else on a 680x0 bus, such as what Majsta has talked about for a while. Trying very hard to encourage him to do some simulation of his idea rather than just put stuff onto his Amiga and consider the Amiga boot colors on monitor as is VHDL debug method. I didn't realize there were others like Robinsonb5 doing similar sounding things. I do have an idea for a modular classic accelerator board that this is a small part of. But having a softcore 68000 doing bus cycles to compare with Motorola/Freescale spec is important to getting things happy with a real Amiga.

I'll probably be poking around with Easy68k for a while when I get time, as for now I'm stuck mostly with Windows until I get a new laptop. The one I have doesn't have room for Linux or much else right now. :/ I don't really plan to do any real assembly software for Amiga users to run on their machines, only what I need to do for hardware simulations of things attached to a 680x0 softcore. Such as eventually my Zorro to Wishbone bridge project at Opencores, probably first connected to ao68000 for simulations and experimenting, then at some point to Minimig via some 68k to Wishbone bridge.

[billt]

Originally Posted by robinsonb5

Beyond that I guess the biggest Amiga relevance is simply that an Amiga forum is a good place to find people with 68000 expertise!

Indeed, I was actually pointed here to ask about 68k things like this. And in time I'd like to do this in WinUAE instead of in Easy68k, but I need time to get to that and I won't have any for a couple weeks yet. As I've done C programming before for AmigaOS but not Assembly, any tips on Amiga assembler tools, how to code, good references and such are what I'm after.

My wife and I hope to get a bigger house this summer and if that works out then I really really want to get my real stuff out of storage and running again, as it's been a few years since I've had opportunity to really use AmigaOS at all. My classics and XE are lonely and dusty in the stuffed room of which we do not speak.

[ramparts]

hi while you people burn fuses over your heads make amigas alive agin keep the good work on projects and fpga´s ,the problem is that when somebody gets there like other simillar projects thing on money and that is were the projects die,like amiga one and ppc and sam boards .

[robinsonb5]

Originally Posted by billt

My interest is Amiga hardware, in the sense that Minimig is and that an FPGA can pretend to be a 68000 or something else on a 680x0 bus, such as what Majsta has talked about for a while. Trying very hard to encourage him to do some simulation of his idea rather than just put stuff onto his Amiga and consider the Amiga boot colors on monitor as is VHDL debug method.

Speaking of debugging, I'm rapidly becoming a big fan of SignalTap.

I didn't realize there were others like Robinsonb5 doing similar sounding things.

Hehe - that's something new for me - and if you'd told me even two months ago that I'd have spent tonight trying to create a caching SDRAM controller for a 68000 softcore I wouldn't have believed you!

I do have an idea for a modular classic accelerator board that this is a small part of. But having a softcore 68000 doing bus cycles to compare with Motorola/Freescale spec is important to getting things happy with a real Amiga.

Yeah I imagine that's the tricky part - though Tobiflex has done it.

Such as eventually my Zorro to Wishbone bridge project at Opencores, probably first connected to ao68000 for simulations and experimenting, then at some point to Minimig via some 68k to Wishbone bridge.

Now that would be very interesting!

As for coding on the Amiga, and suitable software, I tend to use SNMA as an assembler, and monam2 from the Devpack2 package for debugging - but having been absent from the Amiga scene for a good many years I've no idea what else is available now!

[billt]

Originally Posted by ramparts

hi while you people burn fuses over your heads make amigas alive agin keep the good work on projects and fpga´s ,the problem is that when somebody gets there like other simillar projects thing on money and that is were the projects die,like amiga one and ppc and sam boards .

My biggest problems are time and space. I have a large number of ideas and not very often time to work on one of them. And then with no good place to tinker outside of my laptop's imagination, it's hard to do some things when I do have some time. But I do like going back to school to learn more about how to do things like this, so I'm that much better able to if I could.