The obvious way is to get the old hardware, like e.g. Atari 800 XL (for the ANTIC and P/M), an Amiga with AGA chipset (for HAM6/etc), etc, and then install/collect/get somehow an (I)DE/SDK, and then, start playing with the aforementioned things.
Another way is to download the already existing, and working quite well actually, emulators for Atari, Amiga, etc - it's the fastest and the cheapest way :)
There is also a third way - you can create an emulator of such chips (like ANTIC or HAM6 supporting one, not the whole Atari/Amiga). Well, it wouldn't have to exactly emulate the original, just "similar" would be enough. And then, you could play with it - this way is time consuming, but it has some additional educational & research qualities.
Of course, one could go a step further, and create a framework for creating such emulators - and this is exactly what HWFramework is^H^H will be.
To be more precise, the HWFramework will be:
* an educational framework
* a skeleton for creating emulators of the whole computer systems
* a set of ready-to-use external device emulators, like CRT/LCD display, keyboard. mouse, speaker, etc
* a set of some exemplary internal (system) devices, like memory controlers, timers, etc
And all that in C++ and open source.
What's the most important for me, is that one should be able to create a whole computer system using this framework, including a graphical adapter (dedicated CPU + firmware), a network card, etc.
The whole project is purely educational - HWFramework will never be super-fast (I've reached 1.5 MHz during my tests, and some of my readers on the Polish side of the mirror report reaching 2.6 MHz), nor will it be usable for creating real-time emulators of existing computer systems - this is mostly related to the assumptions I've made during the design phase:
* there is only one common bus for all the devices to be used, and the data has to be multiplies of a byte (as in 8 bits)
* there is only one common clock for all the system, which btw is variable, depending on the device speed (so it can be 1MHz this second, and 0.5 MHz the next)
* there is only one common interrupt controller (update: actually I've removed it recently since it was redundant, so it's present in this release, but it won't be in the next one)
The goal of the above assumptions is to simplify the creating of a new computer system (e.g. you don't have to mark which port of which device is connected with which port of another device, since the bus is common anyway), but, at the same time, they deny the possibility to mimic an existing architecture, be it x86 or something else.
OK, now, why would someone use this? ;)
So, everyone who is interested on how does a graphic card work internally, please raise your hand :) Well, using HWFramework you can e.g. create any graphical card that you would like, and your only limited with your imagination (and the clock speed, and some other things too ;p). So, you can:
* think how your graphical adapter should work (e.g. should VRAM be accessible from the main CPU? should it implement 320x200x8bit with a color palette?)
* design and implement a dedicated CPU emulator for your card (the registers and instructions might be a little different than in a general purpuse CPU)
* write the firmware for the CPU of your design, that will, from one side, give an API to the other devices (the main system CPU), and from the other will handle sending data to the CRT display (yes, you have to handle stuff like vsync, etc :)
* you can also write a test program for the main system CPU and display something using your own graphical adapter card :)
* and then, you can add more stuff like, let's say, a blitter, sprites, HAM6 mode, and maybe even 3D! ;>
Now doesn't that sound fun? :)
Anyway, I've just got started with the project, and there are only a couple of things that are actually done:
* the main skeleton of the project: the ports & the common port bus, the interrupts (update: that actually were removed in the newest, not yet available, build), base class for the CPUs
* an emulator for a CRT with the functionality being mostly implemented (only some details are missing)
* a simple emulator of a memory chip with built-in 64KB RAM and 16-bit address bus (I'll add a more interesting memory controller later on)
* some pieces of a test CPU and some test code for it
Some base functionality is still missing, and also the most important thing is missing - the documentation. But I'm working on it.
Anyways, below you can download a zip file with the current version of the framework (that would be 0.0.1.prealpha.1). I'll probably upload a new version in a few days, with some base changes, and also with a new memory controller.
And then I'll also decide if I really want to continue this project :) It'll really depends on the feedback I'll get :)
That is it for now :)
By the way...
If you'd like to learn SSH in depth, in the second half of January'25 we're running a 6h course - you can find the details at hexarcana.ch/workshops/ssh-course
hwframework_release_0_0_1_prealpha_1.zip (414 KB, Source + Windows EXE)
P.S. the current version is for Windows only, however I'll port it to Linux-based OSes later (the dependencies are caused by the window use in the CRT hardware and native fibers used in the base CPU class)
P.S.2. I'm not putting it on any online code repository, since I'm not sure if I'll continue this project. Nor have I yet decided on the license (but it will be either MIT or BSD-style)
Add a comment: