A Better 65C265 Board
-
DerTrueForce
- Posts: 483
- Joined: 04 Jun 2016
- Location: Australia
Re: A Better 65C265 Board
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.
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.
- BitWise
- In Memoriam
- Posts: 996
- Joined: 02 Mar 2004
- Location: Berkshire, UK
- Contact:
Re: A Better 65C265 Board
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/D ... 01361G.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.
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/D ... 01361G.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
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
Re: A Better 65C265 Board
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.
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.
Re: A Better 65C265 Board
Quote:
I'm trying to understand the mindset of people who don't like FPGAs
This also highlights the problem of team projects like this. Everybody's got different goals, and different ideas about how to get there.
Re: A Better 65C265 Board
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 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.
Re: A Better 65C265 Board
BigEd wrote:
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.
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/
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
Re: A Better 65C265 Board
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.
Re: A Better 65C265 Board
BigEd wrote:
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.
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/
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
Re: A Better 65C265 Board
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!
Re: A Better 65C265 Board
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.
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.
Re: A Better 65C265 Board
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.
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.
Re: A Better 65C265 Board
BigEd wrote:
I'm trying to understand the mindset of people who don't like FPGAs.
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.
Re: A Better 65C265 Board
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?
Re: A Better 65C265 Board
BitWise wrote:
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.
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.
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.
Quote:
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.
Quote:
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/D ... 01361G.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.
http://ww1.microchip.com/downloads/en/D ... 01361G.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.
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.
Re: A Better 65C265 Board
whartung wrote:
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.
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.