He said he wanted to avoid FPGAs, microcontrollers, etc. but as I understand it, he wasn't ruling them out completely. I do think it's the only reasonable way he's going to get the kind of video output he wants.
His idea of a parallel interface seems on-theme for what he wants to do.
I really think he should ditch the '265 as a part of that project, though. I reckon it'll cause trouble down the track. But then, I just don't like the way the part seems to be set up.

One of the biggest things I don't like about his arrangements is the facebook group. It means you can't even see any of the discussion unless you have a facebook account, which locks me out completely because I don't have one. I'd be interested in following the progress of that project, but it looks like it's just not going to be public.

Also, is he aware of 6502.org at all? The way he's talking, I'd suspect not.

There is no consensus in the group at the moment about anything -- and probably never will be.

I'm personally not keen on his idea of keeping the hardware and software 'closed source'.

I think he'll find it difficult to find licenseable software to run on it -- just look at our recent discoveries with EhBasic which previous would have been reasonable choice. Everything may have to be developed from scratch pushing out the delivery times.

To meet his $50 target it probably needs to be a really simple SBC otherwise it will be much much more expensive.

Adding memory mapped video is never easy and probably requires an FPGA to act as a memory controller and video generator, otherwise you need a much bigger PCB and a load of discrete chips as Oneironaut has shown.

Providing a USB or PS/2 port for keyboard is a lot cheaper than having a built in keyboard (especially if you use good quality key switches).

The 65C265 is an easy to use chip but is rather limited. A proper 65C816 design would be better in the long run. Maybe the 265 has a place as an early development platform while the real hardware is designed.

I know we are all 6502 fans here but realistically why not go for something more modern? For example one of these ...

http://ww1.microchip.com/downloads/en/DeviceDoc/PIC32MZ-%20Graphics-(DA)-Family-DS60001361G.pdf

... gives you a ton of processing (330MIPS), 640K SRAM, 2MB Flash, lots of I/O options (6 UARTS, 6 SPI, 9 Timers, RTCC, SDHC, ...), 32MB DDR2 memory interface and a graphics controller. All for £15.12. I'm sure other similar modern chips are available.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I think the 265 is a win, isn't it, for having the integrated peripherals? And a PS/2 keyboard is a good choice if you want to avoid complex black-boxes. The sound and video are troublesome though - especially if you want HDMI. Composite, RGB and SCART should be straightforward, there's just the matter of the controller chip.

I'm trying to understand the mindset of people who don't like FPGAs. It's possible that a fair number of them would be happy for individual recognisable roles to be filled by FPGA, but not happy to see a whole system. In other words, the board-level system design should be recognisable.

Even the retro computers of the time had ULAs and custom VLSI devices. To me, it seems perfectly reasonable to put a FPGA in the same role. You can still use discrete CPU, memory and a bunch of other things to make it very similar in spirit.

This also highlights the problem of team projects like this. Everybody's got different goals, and different ideas about how to get there.

Yes, it seems reasonable to me too. But earlier this year one experienced retro-historian believed, and was seriously trying to argue, that FPGAs count as emulation, in the sense that by having to load a configuration they are running a program. I maintain that this is an unproductive and unhelpful way to look at it, and indeed an inaccurate way!

I noticed in the YouTube comments quite a few people feeling that Facebook was a poor choice of venue, and locked them out, as indeed it locks me out. But again, from a marketing perspective, the bulk of the likely customers are probably going to be on Facebook. So it may be a representative forum, without being an all-inclusive forum.

Absolutely true though, everyone has different assumptions and different values. It would be a mistake to try to make a project which will please everyone. But this fellow has shipped large numbers of something (boxed software? Yep, a game, 2500 copies sold...) and presumably knows about economies of scale, and the difficulties of production, so he should have the experience to try to pitch it right for his business model.

I'm not using an FPGA/CPLD in my current project - not because I don't like them but for a few reasons - the first one is the "here be dragons" aspect. ... That boils down to me never having used one in the past, but sure I can learn, there's also the footprint - PLCC socket - but my CAD doesn't support that (and yes, moving from Fritzing to KiCAD is on my to-do list), also the tools to design and program them predominantly run under Windows - and while I've no real hate for windows, but I'd really not use it where possible having worked with Linux and Unix before that for the past 30+ years. (the only Windows system I own is an old Win XP laptop and I only resurrected that so I can program GALs, although I run the 'compiler' under Linux)

There is also the "retro" aspect too, however I am using a GAL - because PALs were around in the early 80's (as were ULAs) so I don't feel it's too out of place.

For 8-bit Daves project - I'm thinking it's more the "here be dragons" aspect than anything else - one of his desires was a system that could be more or less fully understandable by a single person and I appreciate that, but mybe you need to draw the line somewhere - like using a Pi/Gameduino/Blob as a black-box graphics device.

-Gordon

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

Thanks for explaining your thinking! I've no problem with FPGA-free projects, especially if they are aiming to be 5V and through-hole. I suppose I feel that retro projects also includes some FPGA-containing projects, or even FPGA-only projects, and I get the impression some would disagree with that.

When I started my project, I quite quickly came to the conclusion that "true" retro really isn't possible now. Sure - I could go to ebay and get an nmos 6502, one of the CRTC chips, a raft of TTL, even the old sound chips used in the Beeb (or c64), and that might satisfy me..... But ... I have a few friends who said to me "want" when I first mentioned it to them, so making something that's more than a one-off may be a challenge. It's also true that my hardware experience stopped at 5v, through hole too, but soldering up some SMT stuff is not totally alien to me and I'm now seriously looking at the options for my '816 board. (which may well be a '265 one)

So I'm looking at something with a "retro feel" that I can make with off-the-shelf components and as simple as possible - and a real 6502 is retro enough for me, but I want it real - anyone can emulate a 6502 at 250Mhz, but having a real one run your code is, I think, more satusfying. My only (off the shelf) sticking point right now is the Lattice 22v10 GAL - I can get them by the 1000 of ebay and so-far the dozen I've bought have worked perfectly, but who knows... The Atmel 22v10 ought to work, and is still in production and I have a few - if only I could program the little blighters....

My big compromise which Dave isn't that interested in is using an ATmega as "glue" and bootstrap. (But he wants an Arduino header platform?) For me, a ROMless system is a boon - no extra decoding, no wait-states for slow devices, fast turn-around for code development and the addition of a serial port, video (which I'm probably going to drop), and using it as a smart filing system (code on the 6502 talks to the outside world either via my small monitor - e.g. EhBASIC, Applesoft, or via an interface with names like OSBYE, OSFILE, etc. which may be familiar to one or 2 here so it can run BBC Basic, etc.)

But it's not a C64++ or whatever..

-Gordon

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

Yes, making a viable project and also making it recognisably a member of an existing lineage like C64 or ZX Spectrum is a tall order. A viable project is a thing in itself!

The things that made the C64 special were the VIC-II and the SID. Together, they gave what was otherwise a very modest microcomputer capabilities normally seen only in arcade cabinets (at the time). Honestly I don't know of anything hobbyist-accessible that even came close to what the SID provided. Emulating the SID with a microcontroller is doable (and has been done), but there's no direct replacement for the VIC-II, whose most subtle quirks are now relied on by democode even more than the SID. It's probably possible to rebuild one in discrete logic, but it'd be a big job.

Today's 6502s and support logic are capable of running many times faster than the originals, and today's capability expectations are that much higher to match. We want to drive SVGA monitors instead of having to dig out ancient PAL and NTSC compatible stuff and suffer the blurriness inherent in their technology, and we still want the capabilities of the VIC-II if not its quirks, if we are to write any sort of decent games or demos for it. Unfortunately that means building some pretty complex and fast-acting logic. Something morally equivalent to a 6845 is much simpler, but just yields a dumb framebuffer with limited capacity for animated graphics (without applying serious computational horsepower).

The trouble with FPGAs and even CPLDs, from my perspective, is that the tools are proprietary and suffer from all the usual brain-damage of proprietary toolchains. The detailed specifications necessary to develop your own logic-programming tools are simply not available, even if you accept that the vendor's own optimisation algorithms are likely superior to anything you could do yourself. Additionally, devices with significant capabilities tend to have high pin counts and are consequently difficult to hand-solder. This entire class of devices is therefore a bit off-putting for a hobbyist.

By contrast you could write a GAL fuse map by hand if you really had to (though I'm not aware of any open-source GAL toolchains), and a reverse-engineered programming method for at least one vendor's GAL chips is available; PALASM and WinCUPL are both relatively well-understood and vendor-neutral. Programming the smaller microcontrollers is also relatively accessible, as the instruction sets and hardware interfaces are well documented by their vendors. Both remain in production in low pin count packages (PDIP, SOIC) that are easy to work with by hand.

I think it's perfectly reasonable to use a small, cheap microcontroller as a coprocessor, especially if you write its firmware yourself. The trick is to make it firmly subordinate to the retro CPU you're attaching it to, and not to use a device that is too independently capable. A Raspberry Pi would run afoul of the latter restriction - it's exceptionally capable, but very quickly the temptation is to just abandon the "host" and program the Pi directly. But something like this offers a worthwhile challenge to use effectively.

I like the 8-Bit Guy's stuff but he does annoy me sometimes. I actually sent him an email a while back asking if he wanted to collaborate on something VERY similar to what he is doing. He responded that it would be a waste of time and no one would have any interest in it.

Now, I realize he has 875K followers and he probably gets 50K emails a day. So I let that slide.

I think he's in for a rude awakening when he starts developing a full blown kernel. I'm not saying he can't get it done. But I'd bet he's not expecting it to be as difficult as it is. A kernel as advanced as the Commodore 64 is not trivial.

Fortunately for him, he has great connections, can devote his full-time job to it and (apparently) has Bil Herd on his side.

I wish him luck. But I'm just not that interested in what he's building. It seems more along the lines of a SNES than a Commodore 64.

_________________
Cat; the other white meat.

It's not that I don't like them (I really do), it's just that if I were building a project that could be built by others, and a large portion of my target audience were inexperienced people (teens, hobbyists, etc.), then FPGA can really be daunting. I imagine trying to explain to my son how to install the behemoth FPGA tool chain. It quickly turns a simple, fun, hobby project into a chore.

Now, I'm onboard with micro-controllers being in the mix for retro gear. Mainly because many of the more popular ones work with the Arduino tool chain. And it's not too inconvenient (usually) to install the Arduino tools and upload a sketch. Or, I could upload the sketch to the mcu myself and just package it with my kit. No tools (other than an iron) required.

Anyway, like someone else said...we all have different goals.

_________________
Cat; the other white meat.

It's true, if it's a kit rather than a product, the FPGA programming is part of the story, and makes it all much harder. But an FPGA with it's configuration, once it's final, is not unlike a custom VLSI. There's a big difference between a developer and a consumer in this. It's a bit similar with using a microcontroller for some purpose: is it ready-programmed with some fixed function, or is the use expected to update firmware or even compile it from source?

As I mentioned before, he wants to make a product, not necessarily a machine for him self. Rather he wants to sell a machine he'd like to buy. Which is all well and good, but especially with something like this, there's money to be made selling completed projects even if everything from the board layouts to the tool chain is made public.

The dearth of progress on the other projects is telling in that either the folks doing them aren't determined, or the market is shallow to not make it worth getting invested in.

I don't know if any of them are using "kickstarter" like funding, something I've always been basically very wary of.

The "retro" market for a incompatible device has to compete with other small computers (i.e. the Rasp Pi), for more money, and less functionality.


Seems a lot of projects have died on this hill. I've suggested in the past (as if I have the vaguest notion of what I'm talking about) that "someone" create a programmable logic CRTC chip. Like a VIC, or an ANTIC, or the 6847, or something like that. I don't know anything, but the 6847 was used everywhere. A modern, available substitute that can be used by hobbyists I think would be interesting. But, again, it seems many of the retro community are only interested in games, so it needs sprites and what not. They're not happy getting a VGA display driven.

These modern SoC's are simply extraordinary. I've run entire companies and offices on far less.

The issue with these chips, is that you inevitably "put linux" on them, and any charm they had beyond being a board that's 2x3 inches in size is lost. A shell prompt is a shell prompt. "Whee". I am completely sympathetic to this POV. Back in the day, during the Unix heyday, a client asked me which machine they should buy, and I simply told them that I didn't care as long as it ran Informix (the DB development software we used), and had a modem. We had clients with HPs, Sequents, IBM RS/6000, Data Generals, AT&T/NCR, x86 machines, Sun. The admin menus were different, but beyond that -- pretty much all the same to us. The computer makers were doing the Ford vs Chevy sales pitch, while all we cared about was the steering wheel and gas pedal.

Today, I conflate the FPGAs with the custom ASICs of yore. I don't know much about them (I avoid the programmable logic topic on this forum -- it's mostly gobbledy gook to me). I thought an FPGA could be coded like a EPROM or other persistent device. I know, "Field Programmable", but I still thought you could make a design, make a "chip" and then just ship out the chip. I didn't think they were all volatile. I don't have a problem with a black square, with metal pins, that does "Video Stuff". I don't care how the logic got shoved in to it, it's all the same to me.

I think the Gameduino is neat. I look at the Oberon FPGA workstation computer as being pretty neat as well. Custom RISC CPU and an entire OS in a high level language Not C running Not Unix -- with graphics.

(Most) hobbyists aren't in to cycle stealing, bus mastering, DMA, and all of the other shenanigans the old machines had to jump through to get graphics. Which is part of what makes hobby video so difficult, because it was absolutely necessary since the video displays consumes a significant portion of the computer resources. The old machines were sophisticated video displays that occasionally ran BASIC rather than the other way around.

Personally, for a retro machine, I think memory mapped video is a requirement. BALL=113: POKE 32768, BALL is just fundamental to the feel. Having "raw" access to the display in contrast to making API calls across a channel. Just not the same. Otherwise, you're just using something akin to a smart terminal (IMHO).

Mind, it's not a goal of mine. The hardware is over my head. Y'all are hardware geeks here, I'm a software and systems guy. But I think it's key to a "retro" experience. Having a chunk of your limited RAM dedicated to the screen is an interesting resource.

I'm also an Atari guy, not a CBM guy. I never cared for the C64. I thought the Atari hardware with its graphic modes, character sets, display lists, etc. and orthogonal design in the ROM was much more interesting. BASIC being on a cartridge was a feature.

Has already been done. The F18A is a 100% cycle accurate, DROP-IN replacement for the TMS9918. Also has new enhancements like extra layers and scrolling, built in GPU, etc.

Only problem is that Matt isn't making any more of them (I own one). He is, however, working on a replacement that is more powerful. But we don't know when that will be available.

A collaboration between Matt and Murray would be an option. I think the F18A is a MUCH better choice than the Gameduino.

_________________
Cat; the other white meat.