It’s not in English, but there are subtitles.
It’s not in English, but there are subtitles.
Yes, I know there are others. Newer versions of GCC too!.. but I was more so curious to see if I could do it. I know there were GCC 1.x ports to the Amiga but I can’t find source anywhere. And for some reason the Amiga and Atari ST seem to have never been mainlined into GCC. I would have thought 1990-1992 they would have had far more users than say SUN-2/SUN-3.
Some ‘fixes’ are described in this file:
Although it’s not 100%.
I downloaded the files mentioned on this GCC page, and started to massage stuff. This was easier as GCC 2.7 & Binutils 2.8 both support Windows NT 3.5 (and much much higher!).
I may want to try to get an ancient Nethack to build, so I put it onto sourceforge…
I’ve just tested a hello world type executable. I’m more so amazed that it linked and executed, ‘file’ detects the objects as
x.o: raw G3 data, byte-padded
But at least the executables look right:
hi: AmigaOS loadseg()ble executable/binary
I had to hack all kinds of crap compiling eamiga.c
and eamiga_bss.c as neither generated correctly, and both had all kinds of missing and undefined things. I’m sure on bigger projects it’d just explode, but right now I’m just amazed the linker could pick up my object, plus the 21 year old objects + libraries from that aforementioned ancient GCC port.
Oh well I was entertained for a couple hours.
Amiga port of Sozobon, Limited’s C Compiler. Can completely compile
itself, supports 32 bit ints, and optimizer can ‘registerize’ variables.
Includes compiler, optimizer, tool for creating interface code for Amiga
system calls, startup code, C library, include files, and library routines
that work with Motorola FFP format. Uses assembler A68k, linker BLink, and
provided run-time shared C library CClib.library.
And isn’t that great? It even supports 32 bit integers! I had to massage things in Visual C++, as there was some weird instances of return codes missing, and the optimizer not actually mallocing it’s memory, but just blindly using pointers. As always if you can see what is going on in a debugger it’s not too hard to make some wild guesses and get it running, and if you get lucky it may even work too…
With the compiler and optimizer running (it is actually needed to run to further massage the assembly output into something the Amiga a68k assembler can read), it was time to look at an assembler. For the heck of it, I did try a68k, and to my amazement it did actually work, once I had updated the file output call.
hcc\hcc -L hanoi.c hcc: version 2.0 Copyright (c) 1988,1989,1991 by Sozobon, Limited. Amiga Version 1.1 by Detlef W³rkner. hanoi.c: top\top -v hanoi.s h2.s top Version 2.00 Copyright (c) 1988-1991 by Sozobon, Limited. Amiga Version 1.1 by Detlef W³rkner. hanoi.s: Peephole changes (1): 8 Peephole changes (2): 1 Peephole changes (3): 0 Instructions deleted: 3 Variables registered: 0 Loop rotations : 0 Branch reversals : 0 Branches removed : 4 a68k\a68k -q100 h2.s 68000 Assembler - version 2.61 (January 11, 1990) Copyright 1985 by Brian R. Anderson AmigaDOS conversion copyright 1989 by Charlie Gibbs. Assembling h2.s PASS 1 line 59 PASS 2 line 59 End of assembly - no errors were found. Heap usage: -w2047,80 Total hunk sizes: 94 code, 10 data, 0 BSS
wow wasn’t that fun! I haven’t seen the source code to the BLINK linker, so I just end up using a native linker, BLINK.
Much to my amazement, the a68k assembler functions just fine as a cross assembler, and I only had to copy the object file into the emulator, and I could happily link.
The syntax for BLINK was a little strange, mostly because I really don’t know what I’m doing.
BLink LIB:HCC.o+hanoi.o LIB LIB:HCC.lib+LIB:stubs.lib TO hanoi SC SD VERBOSE
Now to try something bigger, like the ancient 1987 vintage InfoTaskForce. I had to add in the include files from the DICE compiler, and surprisingly, in no time, it was all compiled, and assembled the only step remaining was to run the BLINK linker. This time it was slightly different as now we had a bunch of object files:
BLink LIB:HCC.o+fileo.o+funcso.o+infocomo.o+inito.o+inputo.o+interpo.o+ioo.o+jumpo.o+objecto.o+optionso.o+pageo.o+printo.o+propertyo.o+supporto.o+variableo.o LIB LIB:HCC.lib+LIB:stubs.lib TO infocom SC SD VERBOSE
Running that as a single line (or better in a command file) got me my executable.
And it linked without any unresolved externals.
And even better, it worked. Here it is running Planetfall!
I can’t imagine it being all that useful for anyone, as Sozobon C is K&R C, and well this is for the Commodore Amiga, not exactly a mainstay in this day & age.
HCC_Sozobon_win32cross.7z This link will take you to the sourceforge page, and the archive contains both source, and executables. As mentioned I didn’t see any Amiga linker that has source code, it seems everyone use BLINK, and the team that write BLINK went on to re-write all the ‘c’ commands in AmigaDOS from BCPL/asm into C.
I just discovered vlink after writing this, and now I can link a working executable under Windows 10! Since I made zero changes to vlink, and I’m not charging money, I am free to redistribute this so I’ve updated my archive, and included it.
I saw this awesome link over at archive.org’s software Library featuring the Amiga
Behind it all is the Scripted Amiga Emulator. What is more interesting is that there has just been a MASSIVE update/rewrite to the project and it is now boasting far more features!
Looking at the features page, there has been quite a number of updates since the last version. The big ones (to me) is that the CPU core has been rewritten, and now supports not only the 68000, but the 68010, 68020, and 68030 (only with fake MMU). OCS, ECS and now AGA as well! Preset models include the 1000,500,2000,500+,600,3000 and 1200. IDE disk files can even be mounted for the 600 & 1200!
I’d highly recommend the internet archive link, you can jump right into some great Amiga action with nothing to download or install!
WinUAE 3.3.0 (06.06.2016) ========================= New features: - New optional "indirect" UAE expansion trap system, fully compatible with OS 4.x, virtual memory and some debugging programs. - PC Bridgeboard disk drive raw image support. (ipf, ext adf,...) - Monochrome video out emulation, including A1000 color/mono video out software control (BPLCON0 COLOR bit). - Dark palette fix option to correct colors of badly ported Atari ST games (Midnight Resistance etc..) - Official CSPPC/BPPC flash updater can be used to install full ROM image without having existing ROM image file. - Custom input events can execute Amiga-side commands and scripts. - Windows clipboard to emulated Amiga keyboard paste support. - Variable refresh rate optimized vsync mode (G-Sync/FreeSync). - Black frame injection is supported in variable refresh modes. - IVS Trumpcard Pro/GrandSlam SCSI emulation. OS4.x supported UAE expansions: - Directory harddrives, including on the fly insertion/removal. - CDFS CD mounting. - Clipboard sharing. - uaegfx RTG. - uaehf.device hardfiles. - Virtual mouse driver/magic mouse/tablet mode. - uaenet.device. - uaeserial.device. - uaescsi.device. - uae.resource. - uaenative.library. Thanks to all who donated. NOTE: Performance is not (and can't be) as fast as with m68k AmigaOS, especially with directory harddrives, due to slower, much more complex UAE to/from native code context switch trap system. Updates: - Game Ports panel input customization is finally very intuitive. - On the fly input device insertion/removal improvements. - Many input device handling updates and fixes. - Faster screenshot/capture in after filtering mode. - Continuous screenshot mode. - CD32 Akiko chip low level emulation compatibility improved. - Nero .nrg CD image support. Bug fixes: - Hardware RTG emulation rendered same frame twice in some situations causing slow performance. - Amithlon partition type (0x78/0x30) support works again. - Some storage devices failed to mount as a harddrive. - AGA subpixel scrolling glitches. - Miscellaneous custom chipset emulation fixes. - AGA mode HAM6 colors were not 100% accurate. - Some programmed custom chipset display modes crashed. - Direct3D mode DirectX9 not installed warning corrupted memory. - Fullscreen + paused + enter GUI: GUI was invisible. - Display panel gamma value calculation fixed. - CDFS automount didn't mount CDs with empty label.
Download translation DLL: [Default (English)]
I found this the other day, and I thought it was pretty damned impressive.
Kroah has taken the time to reverse how the fractals worked in Captain Blood. From bringerp.free.fr:
The procedural terrain generator uses 1D fractional brownian motion (fBm) with random mid-point displacement. Up to 10 curves are displayed on screen.
When a new curve appears at the horizon, 7 vertices are computed. Then mid-point displacement with fBm are applied to thes 7 initial points. This results in a discrete curve of 512 samples.
The random number generator and the fBm Hurst parameter H are adapted according to the current terrain type (flat, canyon…). This gives very different visual landscapes (plains, moutains, desert…).
No more fractal computation is done on the discrete curve. When a curve is drawn, only 256 of the 512 samples are used (according to the position of the Oorxx).
The view is 256 pixels wide, so if the visible part of the curve is larger than the 256 samples, the curve will be drawn zoomed with pixels linearly interpolated between the samples. Otherwise the curve will be drawn shrinked without any interpolation and using only some of the 256 samples.
The raytraced fractal landscape is computed from these 10 curves.
It’s pretty amazing to think that there was that much behind the game.
I played this back in 1988 on the lowly Commodore 64, but the Amiga version was simply amazing. Such was technology back then.
This one should have been much easier to build, it has support for SDL built in, however the include files are a nested mess, and configure fails part of the way in the process leaving the source kinda messy. But a few hours over a couple of days, and here we are.
This version doesn’t run at warp speed, has sound, and is great. It wants a config file though. You can find the specs in the readme, but something like this:
works fine. This later (and seemingly last) branch of UAE incorporates lots from WinUAE, except for the JIT. It’s dated 2008, so it does include support for the 68030, 68040, and the 68881 and 68882. It doesn’t have MMU support, so things like Linux/AMIX/NetBSD/Enforcer are out of the question.
I dumped my source tree over on sourceforge, as I’m more so interested that this builds using MinGW.
I can’t find any source of the 0.5 versions, and I had issues with 0.6.x but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?). I suppose with this version working I can go back and take a stab at resurrecting 0.6.x
What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.
I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta. So now you can actually use the CLI, and change disks. Double clicking is an impossibility as it simply runs far too fast. I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.
I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast. UAE is from an era where a 100Mhz computer was a luxury item. Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.
Wow what a change from UAE 0.1! We now have colour, mouse and keyboard input, so we can finally interact with the machine. Behind the scenes the biggest change of course was the ‘Heroic effort’ of rewriting UAE from C++ into C. It certainly made reading the code much more easier as nothing is implicit, like it is in C++.
From the changelog between versions 0.3 and 0.4:
960203 filesys.c, action_read(): Slightly more efficient code (translate Amiga address to real pointer). Moved some common code in the generate_* functions in gencpu.c to a separate function. 960202 Added an experimental fast disk option. Currently turned off by default (it's not such a big win). Attached sprite fixes (overlapping att. sprites looked bad, Katakis). Add sleep(1) before resetting the console to text mode when using SVGAlib: this might fix some screen corruption problems. Add sprite/playfield priority checking to the most important case (single playfield, no HAM). In filesys.c, do_find(): open() returns -1 on error, not zero. Return ERROR_OBJECT_WRONG_TYPE if do_find() is called for a directory (fixes Champions of Krynn harddisk installation). 960201 Don't abort if sound driver not present, just set produce_sound to 0. New files keybuf.c and keybuf.h to record keypresses in the right order and without losing any. In cia.c, force 15 scanlines between keypresses, just to be sure. unixfs.device <em>does</em> work with Kick 1.3: just don't trust what Kick 1.3 sends in the startup packet. For now, disable more than one mount per command line. Started integrating Ernesto's new Mac sources. Remove superfluous includes from some files. 960131 Added Ed's unixfs.device (great stuff). Adding ULONGs to pointers is a bad idea on the Alpha if the ULONG value really is signed. Add some casts to LONG in (pc_p + src) expressions in genpu.c. If DMACON is written and copper DMA is enabled, do a COPJMP1 at once. Helps the "Interference" demo. 960129 More SGI fixes from Ed. Bugfixes and transdisk improvements from Marcus Sundberg. Remove EXTRA_DEFINES from Makefile. Breaks some systems. Move common sprite code from pfield_doline() and pfield_doline_slow() to new function pfield_sprite(). The same sprite may appear more than once on the same line, so don't shift out the bits of sprdata and sprdatb while displaying it (Turrican I). In xwin.c and svga.c, barf if LINUX_SVGALIB doesn't match the file being compiled. Make all .o files depend on config.h in the Makefile. No need to exit if sound driver unavailable, but -S given. Small debugger fix: Missing space in output. Fix for the sprite logic: Specifically, use a state variable indicating whether the sprite has been restarted after a VSYNC. Fixes most Turrican problems. 960124 Added Denis Sablic's patch for sound run-time option. Added Ed Hanway's patch for better Makefile, X mouse cursor blanking and more SGI compilation fixes. 960123 Include options.h everywhere. Handle 8 bit GrayScale visuals like PseudoColor. Remove C++ leftovers from joystick code. 960122 When using the joystick driver, the button test must come after handle_events() in vsync_handler(). 960118 Removed all the remaining C++ comments. Changed all inline keywords to <strong>inline</strong>. Define <strong>inline</strong> if not using gcc. Make proper prototypes for everything. Compile with maximum warnings + -ansi + -pedantic. Remove CIA_cycle(), obsolete. Reimplemented the STOP optimization in newcpu.c. Removed DualCPU support in CPU emulator. Real nasty bug in pfield_doline() fixed: sprxpos could be evaluated as negative, with not-so-amusing results. (Need to rewrite this in Oberon to get array bounds checking :-) 960117 Heroic effort: Rewrote the thing in C. This might help fix some problems with users being unable to compile it. Fixed a problem in hsync_handler(): Only call flush_line() for lines in the display window, i.e. when we did a prepare_line() before. Better code for relative branches: Don't use setpc(getpc()+x) calls, increment regs.pc_p instead. 960116 Reimplemented the function to load the Kickstart ROM. Use stdio instead of fstreams since this apparently does not work on the Mac. Detect 256K Kickstarts. Detect corrupt ROM images (calculate checksum). Added Ernesto Corvi's Mac port. Changed it around a bit, so it probably won't compile. 960115 Reinstate config.h options for X screen depth, so that DrawPixel() can be inlined in custom.cc for speed. xlinebuffer is now incremented in each call to DrawPixel() (for both X and SVGAlib) to get rid of some address calculations. 960114 Fixed X generic pixel drawing routine for SHM. Still trying to fix the harddisk emulation. uae.device no longer breaks the debugger (can step through uae.device functions now) Bugs affecting performance: SPCFLAG_STOP never got reset, and DSKLEN() would set SPCFLAG_DISK even if DMA was being turned off. Made slow memory a run-time option. Defer interrupts by one CPU instruction to give programs a chance to read INTREQR ("Seeing is Believing" and "Substance" demos) Added ScrollLock hack for X, too. 960113 SVGAlib version compiles again. Fixed SVGAlib mouse bug. Fixed SHM bug: Maximum scanline is 313, not 312. Sometimes, disk.cc missed a side change and would read the wrong data. Fixed. Apparently, this was the worst compatibility problem. Implemented trace mode. 960112 Changed layout of class amigamemory a little so that gcc can generate better addressing modes. Finally wrote functions in gencpu to generate MOVEMs. 960109 Integrated Ed Hanway's patches for better X support and run-time configuration of some options. Got rid of the direct VGA memory access. (Need to do this differently). Changed the method of drawing lines: custom.cc now tells the graphics code the line number and whether it needs to be doubleed before drawing it. Added Andre Beck's MIT-SHM patch. Remove warnings for newcpu.cc. 960108 Fixed exceptions in op_illg(): Need to decrement PC. 960107 Added an "uae.device" resident module at 0xF00000. This emulates a hard disk (fixed size 8MB for now). 960106 Moved some common code from pfield_doline() and pfield_doline_slow() to a separate function. This fixes a potential HAM bug (two static vars for the same value). Sound support for Linux. Works only with graphics off and the CPU slowed down. Better SVGAlib keyboard support. 960105 Added AvailMem(), AllocMem(), AllocAbs() and FreeMem() dummies. The Hardwired demo times the multiplication instructions and prints "This demo don't like Axel" if they are too fast. Apparently, Axel has a 68040. Added a WANT_SLOW_MULTIPLY option to config.h. Fixed the fast blitter emulation (seems to work now). 960104 Fixed all the ChangeLog entries from 95 that said 96 (oops??!) pfield_may_need_update() should check whether bitplane DMA is on. Added ersatz.cc and ersatz.h. The purpose of these files is to implement one or two Kickstart functions that are commonly called from bootblocks. This should help support some games and demos that only use the Kickstart as an initial track loader. So far, it's only good enough for one program. 951223 More intelligent event handling in the CPU emulator. Slightly faster. 951222 Optimize CPU emulation by inlining cctrue(). Also, the real PC no longer needs to be incremented each instruction. The real PC value now has to be fetched by m68k_getpc(). Added direct screen access for SVGAlib, but it didn't help much. I'll probably remove it again. The gencpu executable is 2M smaller if it allocates memory dynamically. 951216 custom_bput() enhanced a little. Now remembers the value that was written in the other half of the register. Apparently, the USEx bits of BLTCON0 are ignored in line draw mode. (Silents-Demo)
At this point it really does work. However a machine of 2016 compared to 1996 is just too fast. As a result it is once more again unusable. But it makes sense that code from this era would be built to run as fast as possible, however when it really can run fast, watch out!
I found this code while trying to find other older versions and found a post about uae-0.4.hqx, as the hqx suffix denotes that this was the Macintosh port, which thankfully included all the source, and it looks like it pretty much left the source to UAE intact.
It didn’t take much to modify the xwin.c module into a suitable module for SDL, and I was able to get it running on Linux, and with a simple re-compile onto Windows. I did amputate the filesystem sharing code. I could fix it I guess, but considering the insane speed of 0.4, it really doesn’t matter. If you want to test it, simply copy a 512KB kickstart to “kick.rom” and copy an ADF diskette image to df0.adf, and start uae. Unlike 0.1 this will start right away.
It is really far too fast to actually play, just tapping enter after launching is enough to propel you into space in Frontier for example. And as you can see from the egg shape of Aster, older versions of UAE use a 1:1 pixel emulation which stretches, and distorts objects. And it doesn’t correctly detect the screen margins. I guess if it were 1996 it would be worth the time for something like SDL 2.0 where you can close the primary screen, and create another matching the needed resolution on the fly.
For anyone who cares to try my modified version of UAE-0.4 I’ve placed it on sourceforge.
If anyone has any old versions of UAE kicking around, especially any of the 0.5 releases I’d love to know. Every old version I’ve found is here.
Through some crazy search, I actually found the source to UAE 0.1, the fist public release. It’s very simple, and at the same time arguably one of the most important emulators for it’s time as it did show that you really could emulate in software a powerful machine like the Amiga. And with some minor work, I got it to compile on Windows, with GCC 5.1.0
As a comparison here is UAE 0.1 on Linux (Debian 8)
In case it looks like UAE is somehow corrupt on Windows, it is displaying the same thing, except on Linux the X11 it displays the same thing, which is simply runing the 512kb AmigaDOS ROM. I like version 2 or 3 since they have the diskette animation, but the static image will display from version 1.
UAE 0.1 is coded in C++, which only needed minor cleaning up. More so how ‘modern’ machines now use <iostream> instead of <iostream.h> and of course adding:
using namespace std
to get things like cout and friends.
From the ancient announcement:
From: firstname.lastname@example.org (Bernd Schmidt) Newsgroups: comp.emulators.misc Subject: Amiga emulator available (not a hoax!) Date: 30 Aug 1995 11:59:20 GMT I have uploaded uae-0.1.tar.gz to sunsite.unc.edu:pub/Linux/Incoming. The file should move to pub/Linux/system/Emulators in a few months time. "UAE" stands for "The Unusable Amiga Emulator". It is a partial software emulation of the Amiga hardware. It is far from usable, since some vital features are missing, and it is way too slow. However, it should put an end to arguments that it can't be done. There is quite a bit of room for improvements, I expect a full (usable) emulation can be done in about five years time. Don't complain, C64 emulators need a P90, too, to run at full speed, and an Amiga is somewhat more complex. Although this is not a hoax emulator, it can't do more than that: It can currently just display the Kickstart logo. I have not been able to get the disk support working yet. Maybe someone would like to help me, I am rather busy with other projects. The sources are there... UAE runs on Unix systems with the X Window System. I am developing it using Linux, but I have also been able to get it to run on a HP Apollo and a Sun Sparcstation. You need a C++ compiler, or you have to make small modifications to turn it into a C program (nothing major). You also need to transfer a Kickstart ROM image to your PC. The following parts are emulated: - MC68000 CPU: Almost done, some rare instructions (ABCD, ...) are not emulated yet. - Blitter: If there's no bug, it ought to be complete. - Copper: Not much to emulate here - Timers: I think these are fully working, too. Not done properly: - Playfield (display) hardware: Only black & white graphics, no dual playfield support, no HAM. - Sprites: None. - Sound: None. - Mouse, Keyboard, Joystick: None. - Timing: The CPU and blitter cycles are counted, but I have not bothered yet to adjust the timing to match the characteristics of a real A500 - Floppy disk: Broken. I think the hardest parts are done, except the disk support, debugging and speed improvements. Just as a side note: Maybe it might be easier to turn this into an Atari ST emulation first, and debug that. I think the ST has considerably less hardware complexity. If some ST experts would like to work on that, please feel free to contact me. Otherwise, mail me if you have comments, bug reports or enhacements. Regards, Bernd Schmidt
How is that for awesome?
Once it was released naturally there was the temptation to think it was nothing more than a hoax, as there had been another program amibm.zip that did just that display the ‘insert disk’ image and crash a PC. People were of course very skeptical that the emulator was even legit.
: Although this is not a hoax emulator, it can't do more than that: It can : currently just display the Kickstart logo. I have not been able to get the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ha ha ha!! a few lines of code to display an image from a ROM file??? i think so! :) ....its the famous joke emulator thats appeared on Unix instead of a MSDOS PC
And the denial was quite strong!
: If you had read, it comes with ALL SOURCE CODE. Go check for yourself. so?? Its quite easy to knock up a load of source code that looks like it does useful things....or emulation tasks such as emulate a few simple CPU inst. : Next time, read the post. oh, i did, i did....
At this point in 1995, Commodore was dead. A German outfit, Escom had bought them out, but did nothing with it. We were in the post Commodore International days, and it was painfully obvious that the IBM PC of all things was the machine that was going to rule the roost. As VESA added millions of colors, and fast 32bit slots, stereo sound hardware, MIDI synths, and for OS/2 users, yes a 32bit preemptive multitasking OS. Even Windows NT was somewhat usable, and the behemoth that was Windows 95 was just launched.
And honestly if the Commodore HPPA project Hombre had panned out, could Commodore really port exec to a different CPU? Would they just push out a custom Windows NT workstation much like SGi’s Visual Workstation (info)? I’m pretty sure that UAE would have been the silver bullet to their emulation gap of how to preserve 68000 Amiga software on the HPPA. However as a Windows NT machine, Commodore would be reduced to a ‘fancy av card’ that may have carried them on. I don’t think Commodore could have survived making Amiga’s into the late 1990’s and beyond.
Even 21 years later it was still incredible to fire up the first public version of UAE and get the ROM 2.0 animation of the diskette. I know from other changelog’s that the DMA was broken, and that is why it cannot read disks. I don’t know if it’s worth trying to hack in, maybe for another day.
When you start up UAE 0.1, it’ll start in the debugger. You’ll be greeted with:
debugging... D0: 00000000 D1: 00000000 D2: 00000000 D3: 00000000 D4: 00000000 D5: 00000000 D6: 00000000 D7: 00000000 A0: 00000000 A1: 00000000 A2: 00000000 A3: 00000000 A4: 00000000 A5: 00000000 A6: 00000000 A7: 11144ef9 T=0 S=1 X=0 N=0 Z=0 V=0 C=0 IMASK=0 00f800d2: 4ff8 0400 41f9 00f8 0000 LEA.L $400,A7 next PC: 00f800d6 >
It’s a primitive, but effective debugger to step through a program. But we didn’t come here to do that, but rather load up the ROM, and if you have a version 2 or 3 ROM watch the animation. Simply type in f and hit enter, and it’ll “run forever”. On my Xeon it takes about 20 seconds until the Kickstart logo is displayed in black & white.
It’s still very cool to see this early emulator in action, and see where many modern systems first got their 68000 core from.