Hi there! New user here.

I've created something called Turbo Rascal Syntax Error (TRSE) http://www.turborascal.com, a complete modern IDE, compiler and editor for creating 8-bit games and demos in Pascal, with a focus on the C64/VIC20/NES etc, but also has Amiga 500 (M68K) support. You can find a video of the project here: https://www.youtube.com/watch?v=WhJSG7TiHAE

Last week, I finished developing a small demo for the fantastic Pico-8. However, while learning programming for the computer, I sort of realized that the fantasy console doesn't have a CPU, it just interprets code. Limitations are all arbitrary etc. So I decided to experiment with creating my own fantasy computer, but with a *real* cpu - the 6502. I also wanted the computer to be able to draw some "modern" primitives (like PICO-8), so developed a fantasy video chip. Fast video chip + slow 6502 at 1 mhz = lots of fun! I'm currently making a demo / intro for the system as a proof of concept.

The name of the computer? OK64.

Read about the project here: https://lemonspawn.com/ok64/

Here's a link to a video of a program written in TRSE (compiling to assembly -> assembling to .prg) -> being sent to the emulator. SID file is also playing, but sound capture came out all scrambled.
https://www.irio.co.uk/div/ok64_02.mp4


Some stats:
CPU : 6502, 0.958 mhz
Sound : SID chip
Video : OKVC (OK video chip) : 256x256 8-bit VGA-alike with a 256 color palette from RGB 24-bit truecolor. Draws primitives (lines, circles, triangles, blitting data).
64K addressable program memory (PRAM)
1M video memory (VRAM, accessible through PRAM registers $FF00-$FFFE)

For instance, drawing a circle is super easy :
poke( $FF00 , x coordinate)
poke( $FF01 , y coordinate)
poke( $FF02 , radius)
poke( $FF03 , color)
Poke($FF10, 3) (3 = execution ID for drawing circles).

Naturally, in TRSE there are built-in functions "DrawCircle" and "DrawLine" that performs these actions automatically.

Other execution types are drawing lines, copying VRAM data in blocks, setting palette, accessing VRAM memory etc. Drawing stuff is executed by the OKVC immediately, before resetting $FF10 to 0.

You can read briefly about the project here: https://lemonspawn.com/ok64/

So the big question of the day (and the reason that I'm here): Do you guys think that it would be possible to create this computer IRL? I guess that the SID and MOS6502 are easy, but the OKVC..... and I am a complete and total n00b when it comes to hardware!

Usually video hardware of this vintage would not have a blitter or plotter in hardware. That sort of thing was pretty special when the Amiga started doing it, as was the hardware sprite support of the VIC-II.

Having 8-bit pixels does make designing such hardware a lot easier, though you'll end up needing a much higher data bandwidth for video purposes (8MHz is a good value for a PAL dot-clock) than for your 1MHz CPU. It would actually be sensible for you to up your CPU speed to 8MHz, as the current WDC product can easily do that.

Instead of directly implementing a circle plotter in hardware, you should think in terms of accelerating scanline fills. Your CPU then only needs to calculate the X coordinates delimiting each scanline, and feed those to the hardware; you could trigger the operation with a Y-coordinate write rather than a separate memory location, which would make vertical lines and axis-aligned rectangle fills more convenient. This also gives you the flexibility to implement additional graphics primitives, such as ellipses with arbitrary angles, polygons, B-splines, etc without completely losing the benefit of acceleration.

Or you could punt on the state machines required for this, and program a small microcontroller to do it. That's also the accepted method of emulating the SID these days, with genuine SIDs in good condition being increasingly hard to obtain.

Consider, while you're at it, how to handle the CPU being able to generate commands faster than the GPU can execute them. The cheap, lazy option is to block the CPU (deasserting RDY) if it tries to write to the command registers while the GPU is busy. The high-performance option is to insert a FIFO so that several commands can be queued up, and only block the CPU if that becomes full.

Either way, you should try to build a simple machine first to get a sense of just how ambitious you want to be. It's quite possible to build such a machine so that it can be expanded with additional subsystems as and when you develop them.

I'll need to read more about the IDE and expectations of your video/sound system in more detail, but it's not entirely impossible that this computer already exists - or something that might be adapted. So e.g. rather than a set of "poke" commands to a memory location to e.g. draw a circle, how hard would it be to change the code generator to simply make a system call? I'm thinking of my own Ruby816 system (or Ruby6502) - these are fairly simplistic 6502 and 65816 systems that run at 16Mhz with either a serial interface to the graphics (and sound when I get round to it) or (again, plan B) a parallel interface. The graphics engine is separate from the 6502/816 processor and supports sprites/tiles, sound, (bbc micro style, but as it's all software, then whatever)

This is it drawing circles: https://www.youtube.com/watch?v=rPGCT0lah4Q

and the code to generate it: https://unicorn.drogon.net/circles.c

Or adapt it to run on a BBC Micro?

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Welcome leuat!

Indeed, the difficulty with the video chip is that in real hardware it would need to be clocked at some sensible rate and access memory at some sensible rate. Drawing lines isn't too bad with hardware, drawing circles a bit more involved, before long you probably look to a microcoded solution. It will take many clocks to do work which needs to write many pixels.

For some history of the early chips, of about the right timeframe, which could do this sort of thing:

Famous Graphics Chips: NEC µPD7220 Graphics Display Controller
GPU History: Hitachi ARTC HD63484. The second graphics processor.

The difficulty is that hobby projects can't reach the clock speeds or performance of modern solutions. A modern FPGA-based design with external SRAM might top out at 100MHz, and might be outperformed by an emulation running on a cheap ARM. A less integrated design might top out at 20MHz.

Having a microcontroller act as the graphics engine would be a reasonable choice: in retrocomputing everything depends on what compromises you are willing to make. As the first paragraph of your website notes, only you can know what you want to build.