(I think there's still some minority of FPGAs which can contain their own configuration, but most of them read from an SPI EEPROM at power-up. So, it's a two-chip solution, or maybe an N+1 chip solution if multiple FPGAs share an EEPROM. Anyone could sell pre-programmed EEPROMs which turn some particular FPGA into some particular VLSI function. And if were still in the realm of through-hole I can see that working: a 40-pin DIP which does a VIC-II-like thing or a SID-like thing. But surface mount is an extra barrier to fitting FPGAs into the hobby/kit part of the market. The modules you can get, or could get, which put an FPGA into a DIL socket, were pretty expensive for this market.)

Oh, and the F18A page reminds me of another wrinkle: FPGAs take some 100ms to configure, so they are not quite there at power-on unless you have quite a long power on reset time constant.

Depends on what type of project you mean. My own retro style SBC is progressing nicely. I have a working PCB can run various BASICs, working on a filing system and some other nicities, but I'll do a 2nd PCB for the 6502 to test some bus IO facilities and call it quits at that then move onto the '816 (or '265) system by Easter - and by then I'll have a solid software base that will (hopefully) just run on the '816 - in 8-bit emulation mode at least, then I can work on 16-bit'ifying it.

This all started as a vanity project for me about a year ago, I put it on hold through last summer for many reasons but I'm at it now in-between some other work... But - the future? I've no idea. I do (now) have a solid road-map for it, I also have people interested in buying kits - which I didn't envisage, so what do I do? Do I make a 6502 kit for early adopters, then an '816 kit making sure it's backward compatible? It's a weird situation, but it seems there is a market for stuff like this, if somewhat a somewhat niche one.



I've absolutely no plans to use kickstarter, although I know people who use it to gauge interest rather than as a platform to get funding via.




I don't think it does compete - the Pi is for kids, and us oldies who like to tinker, but who doesn't wan't a real 6502 on their desk? Look at the response 8-bit Dave has had so-far, but also - look at the Foenix project - it never had quite the same response and the forums are very quiet, although the board is technically superior!



It's back to the "pixel pokers" vs. those who want tiles/sprites. Also resolution - no-one seems to want composite video these days - that was limited to about 320x240 or so - make that 4-bit colour and you need almost 40KB of RAM and without hardware assist, doing a simple screen clear takes noticable time.

I had that when I wrote my BASIC interpreter - the first thing a lot of people asked me was along the likes of "what are the pokes" - there are none on a Linux system which seemed to disappoint - why poke a number into something to set cursor position when there is a command to do it (was my reply). At the end of the day I do "pixel poke" into an SDL framebuffer. (in the C interpreter thats running the BASIC) It's fast enough to run a 10fps raycaster on a Pi from a BASIC program... But that's not something you can do with a tile/sprite type of graphics chip - unless you can tell the chip to draw a line. Trivial in reality - so my "black box" graphics idea is win-win from my point of view - it's a GPU on a 6502..



You don't have to though. There are some good "bare metal" frameworks for the Pi now. My own plan is to replace /sbin/init with my application that takes commands via a parallel interface and does stuff - so a command might be 5 bytes: plot + X + Y and off it goes, or 9 bytes: line + X1, Y1, X2, Y2.. then once I have the concept, I'll look at the bare metal things. I can boot a Pi into that in a couple of seconds - the PiTube direct runs in bare metal and boots in under a second as far as I could tell...




The BBC Micro introduced the API for me - rarely did you poke the screen - if you did, you knew your code would not run over the Tube... (And did you ever try to poke characters to the Apple II screens with their somewhat interesting but completely logical memory mapping)

Anyway, enough from me for now

Cheers,

-Gordon

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

I'm talking about the other large projects trying to make something for retail sale, vs hobby projects.


Sell the bare boards, instructions, a parts list with suppliers, and a pre-loaded ROM (or whatever).


I honestly don't know what response he's getting, only that it's certainly not a new or novel idea.

Pis have become a universal teaching tool. The Pis success has been extraordinary, I don't know if there's many bare metal "look, Pi with BASIC in ROM" style implementations, or if they have any popularity at all.


But there's no reason that you can't have a "retro chip" that simply scales up to VGA. So, for example, if you have a 40x25 screen of characters. You "poke" character in to the frame buffer, and viola, characters show up on the VGA display. You can have an 8K "hi res" 320x192 monochrome display that's scaled up to display properly on a 640x480 VGA display. Still costs the host CPU 8K, the hardware does the scaling, etc. Yea, you get "big pixels" on the VGA. That's what happens when you get a nominally 12" display blown up to a modern 20+" LCD. I remember back in the day, we bought some 20" tube monitors for a project (Holy Dead Weight were those suckers heavy! We bought 10 of them, for a "airport like" arrivals/destination status display). For a short time, we were just using them -- as 80x25 displays. Boy howdy, were those characters big!

Maybe that's what that F18 thing did.

But this is kind of what I mean by the "feel" of a retro machine (not having worked with a BBC). Over here, we poked everything!

Sure. But someone clever could do a bare metal Pi that boots to BASIC, that lets you "poke" to the screen buffer. When that happens, a VM Page fault can update the "real" screen, or the underlying system snapshots the "retro" frame buffer to the the "real" frame buffer every VBLANK.

Did anyone build up a system that installed one of these, or were they all used as spare parts in existing machines?

…and now my head is swirling with visions of an ARM microcontroller slaved to a couple of EDO DRAMs and some discrete logic to act as a RAMDAC…

Would there be any interest in a small add-on board containing FPGA, pre-programmed config flash, audio/video, and maybe some RAM ? Something like the gameduino, but aimed at 6502/65816 hardware (bus compatible, 5V I/O and 100 mil pin headers). That would allow any hobbyist to add on audio/video, without having to worry about FPGA dragons.

I don't understand the repeated focus on VGA. Isn't HDMI well supported on modern FPGAs now, in terms of both direct TDMS output signals and hdl libraries? Does it bring that much complexity over VGA, assuming a fixed output resolution/framerate on either? Plus, HDMI should be backwards compatible to DVI for "older" monitors.

Separately, I'm from the C64 era of kids. The fun of the machine, and the fun that Mr 8bit talks about is about programming a machine with simple-to-use interactive color graphics and sound. It entices you to see what sort of interesting-looking things you can do, and invites incredibly high levels of interactive and iterative programming within that feedback loop. Even the very simplest of programs (eg, move square with cursor keys) are colorful and rewardingly interactive. Yeah, most of what you make might be game-like, but then there's the demoscene which takes it to the extreme and has nothing to do with gaming. As long as it's actually creative and explorative in computing, as opposed to just "download and play" as a consumption device, it's a great space to explore with an enticing hook.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

> I don't understand...

It's a common phrase, and I've used it myself. To anyone who doesn't share the same generation, the same imprinting, the same fixations, some preferences can seem difficult to understand. The key is that these are not logical preferences: there is no rationale. It's what you grew up with, it's what you prefer.

The big problem with HDMI/DVI is that it's hard to drive from hand-built hardware, requiring signalling frequencies well into the hundreds of MHz - for that reason, support among FPGAs is not really helpful, because FPGAs are not friendly to a hand-built system. VGA is hard enough to be getting on with, but is at least an achievable goal.

A related format, however, is DPI - Display Parallel Interface, which may actually be easier to drive than VGA (because you get to skip the DACs). A standard, well-documented converter module from DPI to DVI/HDMI or even DisplayPort would be useful in this context. There are LCD modules out there which accept DPI signals directly, too.

There aren't, that I'm aware of - yet.

The issue with bate-metal in a moden thing like a Pi is that there is just so much hardware - setup an Apple II from power on - well, poke a few registers to set the right video mode, clear the keyboard input latch, clear the screen, beep and off you go. On the Pi... Well, the GPU boots, does "stuff", loads more stuff from SD, does more stuff, loads more stuff from SD, takes the ARM out of reset - then your ARM code has to do more stuff like setup the MMU, cache, oh, you want keyboard input, well, there's this USB thing, so off you go, write a USB driver. Oh, you want disk? Well, there's this SD card thing, so off you go and write an SD card driver, and so on.

Now.. I think most of this has now been done - I wish I had time to look, and I will - soon. I probably could get my own BASIC to run that way - all I really need is keyboard and mouse input (optional) A filesystem would be nice, but... For video well I use a library called SDL 1.3.. And what that gives me is a block of memory for me to poke pixels into and an "update" command that effectively copies the shadow framebuffer into the real one.

Under Linux you still have access to the real framebuffer - try this: Go into console mode (Somethingl ike Ctrl+Alt+F2) and login. Try this:



and look at those lovely colours

SDL hides some of that and provides some nice colour translations, but to change my BASIC from using SDL to poking pixels - well, 1 line of code. (ok, mayde 3 or 4 lines, but relatively trivial). So all I need is most of a standard C library and some extra bare-metal goodness (ie. usb keyboard) and off I go... I do sprites purely in software because - the Pi GPUI - here be dragons...



I could do that on my BASIC today under Linux - it would take me 10 minutes to write peek/poke into it that was directed at the SDL screen buffer. I just didn't see any advantage doing it. My view was that peek/poke (and their variants) were there simply because of the limitations of the language, ROM space and so on. Why write clearKeyboardStrobe, when poke -16384,0 works. (And while BBC Basic does have peek/pokes it also has a plethora of vdu, plot, etc. commands to do effectively the same thing) Maybe I was just too modern with my BASIC!

I would like to think I could port/re-write my BASIC for the 6502, but I fear it would take too long. However I have a cunning plan and it might not even involve C.

Cheers,

-Gordon

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

The nearest equivalent of "Pi with BASIC in ROM" that I'm aware of is to run RiscOS Nano on a Pi.

Indeed, RISC OS springs to mind (do you mean Pico rather than Nano?) If by 'bare metal' we mean 'not Linux' then that meets the mark. If 'bare metal' means 'no operating system' then we'd need to decide what degree of operating system is necessary for, or present in, Basic. Perhaps we mean 'boot to single application' or even just 'boot very rapidly'. As RISC OS Pico lacks the desktop - it boots to Basic - maybe for some that's enough to call it bare metal.

I'm reminded of the time back in the day when I first repartitioned my hard drive and installed Linux as an alternate boot. At that moment it becomes clear that the personality of the computer is all about what it boots into. The same machine running Windows, or Linux, was a world of difference. This was something I surely knew already, intellectually, but that was the point that I felt it. And so it is with the Pi: the storage you have is an SD card, and if you swap that out and run RISC OS, or PiTubeDirect, or even just a variety of Linux distributions, you should come to feel that it's what on the card that matters - it's not the Pi itself.

Simple ubiquity. More of a model "lowest common denominator" video interface today than composite/rgb. Composite is simpler (I guess), but few people can actually show composite video on anything handy today.

Lots of VGA monitors/LCDs still around. VGA-> HDMI I think is a simple adapter. VGA->Display Port as well.

It's not a quality thing, just handiness thing.

Much like USB now. PS/2 connectors are getting rare today. My most recent cheap keyboard purchase doesn't have the connector. It's all USB.

USB offers this [ ] much capability, and the keyboard uses [], but that's the way it is. 1.5-12Mbps interface for a keyboard. If only I could type that fast lol.

Yea, the Pi is fabulously complicated.

Sure that can work. I think for a retro micro, you just need to interpolate some, since a 2-4Mhz 6502 trying to keep up with a VGA sized color frame buffer just isn't going to work vs "poking" character memory, or some other type of proxy frame buffer.

Well, it's funny, shows you what I know. That TI chip mentioned along with the F18A project. It does NOT share its frame buffer with the CPU, it has it's own, and you communicate with it indirectly via the TI video processor. So, you can't "poke" in to the frame buffer on a system, using the TI chip.

So, you know, the Gameduino, or your layer on top of SDL -- not really different.

It's drawing the line between just putting a "retro" BASIC on a bare-metal Pi (more or less RISCOS style), emulating a 6502 on a bare-metal Pi (been done, runs at 250Mhz) then sticking a 6502 BASIC on that, or using a Pi (bare metal or not) as a "black box" video card.



This is what I've been saying for a while now - and quoting the TI99/4A with the TI9918 (which the F18A is a replacement for) The issue is speed over the bus - and it was earlier conversations regarding GPIB, etc. that got me thinking. It's trivial to emulate a VIA on a Pi, so you get the 6522 hardware handshake going at the full speed the 6502 can drive it at. This is the essence of the data part of GPIB without the bus signalling. Sending, say, a command to draw a line: one bye command, then 2 bytes X1, 2 bytes, Y1, then another 2+2 for X2, Y2 - and the graphics processor draws the line in the current colour. It could even be a 16-bit bus on a '816.

And that could be extended to peek and poke, but you might as well call those plot a pixel, read a pixel. (unless the graphics processor is running in a text-only mode displaying PETSCII or Teletext ... ) then the graphics processor can do anything you care to program it to do - like all the usual stuff like lines, points, geometric shapes, polygons, filled, open, writing text, scrolling, changing the font, sprites and what not.

Poking pixels from BASIC - this will be slower than poking into local RAM (time taken to copy the commands & data over the 8-bit bus), drawing a line from BASIC - faster because it's not 6502 assembler doing Bresenham, but the ARM on the Pi.

I guess the question is then: Is it "retro"? To which the answer could be "yes - we did it that way back in 1981 when the TI99/4A was released", or yes, but you're doing too much, make the 6502 calculate Bressenham or mid-point circle, etc., or "no - you're using a Pi".

I'm going to call it "retro style"

-Gordon

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