This is it. This is was my goal, where I was hoping to be in time for VCF-Southwest at the end of this month — my Wrap030-ATX project is running the TSMON monitor from ROM; the monitor is loading BASIC from ROM into RAM; and BASIC is running programs.
I did run into a few problems getting BASIC running because of all the modifications I've made to it over the years for my 68000 project and the earlier iterations of the Wrap030 project (most problematic being my attempt to modify it to use the FPU).
So I went back and grabbed a fresh copy of the source to work from. I converted the syntax from VASM to GNU AS, swapped out the M6850 ACIA UART routines for new ones using the 16c550 UART, and updated the addresses in the program and my linker script for the Wrap030-ATX memory map. It took a few tries to get it running, but I think the results really speak for themselves.
Now that I've met my minimum goal ahead of VCFSW, everything else is extra. I do want to see if I can get the FPU and my video generator working.
Version Played: Direct C# Port by Michael Birken (No enhancements)
The first Star Trek video game, made for the Sigma 7 and then ported to the HP 2000C minicomputer. These were devices that had no screens, but were instead connected to a printer and printed the new game game as you played.
This game was ported to many different systems, under a lot of different names such as Apple Trek, Tari Trek and Dragon Trek. I have chosen a couple that I will go through with significant changes, as the vast majority run the same, just ported to different systems, with the latest major version being released in 2023.
In this game, you need to destroy a set amount of Klingons in a few days. You need to explore the area, as well as dock at stations to repair yourself.
This game is very difficult, as you need to hunt for Klingons, navigate around and so lots of actual calculations to work out how to navigate as well as aim torpedoes. For such an old game, there is a surprising amount of detail in it, with enemies that attack you, systems that break, scanning and even a built-in calculator for torpedoes.
Your systems breaking are completely random, though, and something like your warp drive breaking can render a playthrough unwinnable as you won’t be able to find a starbase in time. Even without any damage, navigating around is very difficult as you need to set a direction and speed, and take into account both sector and quadrant locations.
Despite all this, there’s just something that’s a lot of fun about trying to do all this with such basic input, having to figure it all out yourself. It’s a fascinating game and it’s definitely impressive for what it was originally made for.
Got bored, decided to start working on programming a quite rudimentary text based roguelike in Commodore BASIC 2.0 like it's 1983, working pretty much purely off of text, so if I ever finish this project, and somehow still have motivation, it'd theoretically be pretty easy to port to anything else running a variant of Microsoft basic.
Only problem is I'm not a programmer or an artist, or a musician for that matter, so if this little project ever does get finished don't expect anything mind-blowing, this is purely a passion project, but I'd love to do a physical release on cassette one day, again, assuming I get it finished. I kept the game to a specific scope to maximise the chance of it actually getting finished and to try and avoid feature creep.
AI Adventures in Programming: Making Basics Exciting!
Embark on an exciting journey into the world of coding with our latest bookmark! 🚀 "AI Adventures in Programming: Making Basics Exciting!" 🤖💻 Discover how AI tools add a sprinkle of magic to your coding endeavors, making the learning process not just educational but downright thrilling! 🌟 Unleash your creativity, solve problems effortlessly, and transform basic programming into an adventure. 🎓🔍 Dive into the realm where AI becomes your coding companion, making the basics more accessible and fun. Ready to explore the future of programming? Join the adventure now! 🌐✨
I came across some early CG I had made while going through my late mother’s things. Coded in BASIC. Output on a Tektronix 4051 while I was a freshman at college. Chairs were easy to model because rectangular solids were easy, and I had to enter all vertex coordinates by hand. I simulated a #fisheye lens. Pure #wireframe. No hidden surface removal. I found an ad that shows what the computer looked like.
I have a CPU board, I have an FPU board, and I have a video board. I know they all work; I know the CPU board works with the FPU board; I know the CPU board works with the video board. Time to bring them all together and see what happens.
It doesn't work.
Well that's disappointing. All the pieces work, and I can use one expansion board or the other, but if I try to use both together, the computer fails to boot.
It will still run if the address and data buses are connected to all three boards, but as soon as I connect the control bus to the third board, everything stops.
I tested the control bus signals one-by-one to see where things broke down. It wasn't RESET#, HALT#, or BERR# (though I really didn't expect them to be a problem). It wasn't the bus size selectors, R/W#, or the Address & Data Strobes. That really only left one thing — the DSACKx#, or Data Strobes Acknowledge, signals.
This is ... Not really surprising. I suspect that it was actually the DSACKx# signals that gave me so much trouble with my original prototype and with the 8kΩ pull-up resistors I used initially. These are wired-OR signals that get pulled low by peripherals or logic to acknowledge and end a bus transaction, and then the pull-up resistors return the signals to Vcc when de-asserted. With a lot of devices on the bus, or long signal traces, the capacitance starts to add up and a high resistor value for the pull-up can cause a slow rise time when the signal is de-asserted. If it gets too long, the CPU will detect the signal as still asserted when it starts the next bus transaction and end it really, resulting in the CPU reading garbage data from the bus.
There are a few ways I could fix this. I could use the equivalent of an AND gate to combine the disparate DSACKx# signals and send the result to the CPU, but this would require a significant amount of rework or even redesign. I could lower the pull-up resistance, but don't have any lower value SIP resistors or a good way to add parallel resistors to lower the value. Or I could try lowering the system clock speed to increase the timing tolerances.
That last option is easy — just replace the oscillator. I swapped out the 40Mhz oscillator for the next highest I had: 25MHz.
And it booted.
It's a little bit slower, but the computer is now running reliably with both the FPU and the Video board connected.
To make the most of the two boards together, I ported the Mandelbrot renderer from BASIC to 68k assembly using FPU instructions. The BASIC program renders a 60x22 image with 31 levels, output over serial as ASCII characters. My best time running the BASIC version was 14 seconds at 56MHz. This new assembly program renders a 160x100 image with 16 levels, output as video ... in just over four seconds at 25MHz.
That is an impressive time, but I'm hoping I can solve the problem with the DSACKx# signals so I can push the clock speed up again. I'd like to see how fast I can get this thing to run.
I also still want to modify EhBASIC to use the FPU. I'm interested to see what kind of a speed difference it would make running the original ASCII renderer.
Version Played: Direct LUA port by Emanuele Bolognesi
Super Star Trek is the first major enhancement of the 1971 Star Trek game. This makes the game much easier to decipher, with some information given via dialogue from the crew, and generally making everything much easier to visualise and making actions easier to perform. Permission was even supposedly given by Paramount to use the name Star Trek.
The regions are given names, and the icons for the Enterprise and Klingons use letters to help distinguish them better. That said, the game is still difficult, losing access to some functions is still a major hazard – I even lost access to damage control in one playthrough.
Super Star Trek is a really nice version of the original Star Trek game.