Change of product direction, good and bad news!

Announcements by the development team or forum staff.
Locked
SolidState
Posts: 13
Joined: Sun Aug 22, 2021 11:53 pm

Change of product direction, good and bad news!

Post by SolidState »



On 9/22/2021 at 1:02 PM, maktos said:




MY POINT: Now that this post has been made, and David has his feedback from the community -- he needs to follow it up -- QUICKLY -- with a firm decision



David hasn't checked this forum in over three weeks and frankly I don't blame him. His interests and productivity lie elsewhere. There is still substantial technical work to do here and even a basic kit release will involve a financial risk I doubt anyone is willing to take. Someone will need deep pockets or start remortgaging property when the unforeseen crowd funding logistics go wrong.

I think the only way forward at this point is to open source the entire project. Sharing all the details with the community will bring in the missing resources and energy to help push this over the line. There could be a sunk cost fallacy here though and that might explain why things have stalled out in this near-permanent limbo.

Ju+Te
Posts: 40
Joined: Sat Sep 25, 2021 6:33 am

Change of product direction, good and bad news!

Post by Ju+Te »


I'm completely new to this project and I might not be fully up to date. I thought, the initial plan was to create a dream 8-bit computer from standard DIL components that will be available in the near to mid future, too (the problem with replicas of older machines is the lack of certain chips, right?). While the VERA looks like a very cool project that possibly can be sold independently, this already contradicts with that idea. Hence, in my opinion, there is no major difference left between having everything in an FPGA or just some major parts. To rebuild or fix this machine in the future, you will need one anyway. Maybe this only can be solved by making the complete hardware (incl. VERA) and software also open source - though I completely understand that the makers want to get their spent money back first.

TomXP411
Posts: 1781
Joined: Tue May 19, 2020 8:49 pm

Change of product direction, good and bad news!

Post by TomXP411 »



1 hour ago, Ju+Te said:




I'm completely new to this project and I might not be fully up to date. I thought, the initial plan was to create a dream 8-bit computer from standard DIL components that will be available in the near to mid future, too (the problem with replicas of older machines is the lack of certain chips, right?). While the VERA looks like a very cool project that possibly can be sold independently, this already contradicts with that idea. Hence, in my opinion, there is no major difference left between having everything in an FPGA or just some major parts. To rebuild or fix this machine in the future, you will need one anyway. Maybe this only can be solved by making the complete hardware (incl. VERA) and software also open source - though I completely understand that the makers want to get their spent money back first.



So you've missed... a lot. 

Yes, the hardware will be an open design. The software was originally intended to be open source, but the team chose to license the Commodore 64 KERNAL from Cloanto, making the operating system proprietary. It is possible to port the portions written by Mike Steil and other users to something like the Open KERNAL written by the MEGA folks (which has been discussed), but I think David decided the licensing option was the simpler way to go. 

From the beginning, David was going to use an FPGA graphics chip. Originally, he planned to use the Gameduino, but the performance just wasn't there (Gameduino uses an SPI serial link), and he ended up trialing two designs submitted by users. The VERA design won out, so that was selected and refined to make the final product. 

So while the video interface is on an FPGA chip, the rest of the system, RAM, I/O, and CPU, all are still discrete chips. 

And yes - I'm pretty sure there will eventually be an all FPGA system. The individual components for this already exist; it's just a matter of someone actually assembling them into a single core that can run on a popular and inexpensive FPGA platform. 

 

paulscottrobson
Posts: 305
Joined: Tue Sep 22, 2020 6:43 pm

Change of product direction, good and bad news!

Post by paulscottrobson »



1 hour ago, Ju+Te said:




I'm completely new to this project and I might not be fully up to date. I thought, the initial plan was to create a dream 8-bit computer from standard DIL components that will be available in the near to mid future, too (the problem with replicas of older machines is the lack of certain chips, right?). While the VERA looks like a very cool project that possibly can be sold independently, this already contradicts with that idea. Hence, in my opinion, there is no major difference left between having everything in an FPGA or just some major parts. To rebuild or fix this machine in the future, you will need one anyway. Maybe this only can be solved by making the complete hardware (incl. VERA) and software also open source - though I completely understand that the makers want to get their spent money back first.



This is the basic argument. 

It's not practical to produce a serious video system without some dedicated chips - even in the early 1980s we had 6847, 6845, 99x8 and various ULAs in machines or dedicated chips. VDUs built out of TTL and RAM chips with an EPROM character generator tend to be late 1970s/early 1980s and many of them used a CRTC. Dave's original idea, which was to produce something cheap out of real parts always was impossible unless you took a Galaiksjan approach to video generation, and while this is very interesting, is limited.

So there's a compromise, which is essentially video on one chip, and everything else with real parts. The main problem with this seems to be timing, which seems to have caused various other CPLD and MCUs to be added (not sure exactly what), and some things moved to Vera. So sound is now on Vera, and it's a moot point whether there's an advantage in having a real sound chip as well. The PS/2 keyboard interface was supposed to be done over the PIA as well, never quite sure how/if that worked given it's a slow clock. It wouldn't surprise me if that moves onto Vera as well.

Then you could get to the point where you've pretty much got a standard 6502/RAM/Flash ROM reference design with all the add ons on an FPGA, with other modern components forming a bridge.

It's supposed to have educational value (I understand the kit builders enthusiasm) but I've actually done this with real children in schools (usually doing on the fly repairs of BBC Micro Keyboards), and there's not a huge amount you can say other than this chip does this, this one does this and so on. it undoubtedly helps bridge theory and reality but they can't experiment with it.. They all look much the same but it takes a few minutes. If you want to get down to the nitty gritty of hardware you'd be better off with Ben Eater's course which is first principles parts but no sort of development platform (as yet) or a basic digital electronics course, if they still do these ?

If you want real chips on there it'd be better to take a leaf out of Alan Sugar's book with the CPC472 and do it on an FPGA and just plonk fake components on. Then you can buy cheap fakes from China and it doesn't matter if they don't work.

 

paulscottrobson
Posts: 305
Joined: Tue Sep 22, 2020 6:43 pm

Change of product direction, good and bad news!

Post by paulscottrobson »



17 minutes ago, TomXP411 said:




So you've missed... a lot. 



Yes, the hardware will be an open design. The software was originally intended to be open source, but the team chose to license the Commodore 64 KERNAL from Cloanto, making the operating system proprietary. It is possible to port the portions written by Mike Steil and other users to something like the Open KERNAL written by the MEGA folks (which has been discussed), but I think David decided the licensing option was the simpler way to go. 



 



Have you had a look at the source ? I remain unconvinced. Apart from problems like the use of the Z-register there's a whole Z80 emulator in there. It's not very clear what any of it actually does and I can't find any real effort to seperate Mega65 specific code from generic code. It also seems to follow the modern tradition of comments being for wusses. Even if it works, it looks in the "nightmare to maintain" category. https://github.com/MEGA65/open-roms

BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

Change of product direction, good and bad news!

Post by BruceMcF »



4 hours ago, paulscottrobson said:




So there's a compromise, which is essentially video on one chip, and everything else with real parts. The main problem with this seems to be timing, which seems to have caused various other CPLD and MCUs to be added (not sure exactly what), and some things moved to Vera. So sound is now on Vera, and it's a moot point whether there's an advantage in having a real sound chip as well. The PS/2 keyboard interface was supposed to be done over the PIA as well, never quite sure how/if that worked given it's a slow clock. It wouldn't surprise me if that moves onto Vera as well. ...



Pinning down some details that are a bit loose here.

There aren't "various other CPLD and MCU's" added due to problems with "timing". The problems with timing were handled by getting the chip select sequence with R/W and clock phase right for the chips which variously expect 6502 style bus timing (leading select), Z80 style bus timings (synchronous select) and PICBUS style timings (leading R/W), but that was a matter of getting the correct versions of chip select signals from the glue logic chip select circuitry, as some needed to be OR'd synchronous with the clock and some needed to be asynchronous.

The problem with timing with the AY3 sound chip led to replacement with a different PSG sound chip, the SAA1099. IIRC, it was mentioned on Facebook that Frank's plan for Vera from the outset was to include PSG capabilities, so PSG on Vera is more about the design goals of the Vera designer making the SAA1099 PSG redundant than about issues integrating the SAA1099 sound chip. The YM2151 is an FM chip, which completes the 1980's "chiptunes trinity" of PSG, FM and PCM.

The MCU is an 8bit MCU ATTiny to handle the power management on the ATX power supply, which is not a pure old fashioned "dumb" power supply but includes a signal from the PS whether some characteristic of the current is valid. The version 1 and 2 prototypes had a circuit done with glue logic which apparently was working with the PS they had but when tried with some other ATX power supplies could be a bit flaky. After all, ATX power supplies assume that the motherboard has a microcontroller handling power on/off etc. It is accessed via I2C bit banged on a 6522 VIA.

The PS2 can't move to Vera, there aren't enough pins. The two options are handling the PS2 with a VIA or handling it with a version of the ATTiny with more pins (which would, of course, be quite period "consistent", as the original AT keyboard/mouse interface that the PS2 was evolved from was handled with an 8bit MCU). If they end up using the ATTiny, then an MCU may end up being used to deal with a timing issue, but it was added to integrate with ATX power supplies under the ATX specification, rather than "it works with what we have on hand".

 

paulscottrobson
Posts: 305
Joined: Tue Sep 22, 2020 6:43 pm

Change of product direction, good and bad news!

Post by paulscottrobson »



On 9/25/2021 at 2:22 PM, BruceMcF said:




The PS2 can't move to Vera, there aren't enough pins. The two options are handling the PS2 with a VIA or handling it with a version of the ATTiny with more pins (which would, of course, be quite period "consistent", as the original AT keyboard/mouse interface that the PS2 was evolved from was handled with an 8bit MCU). If they end up using the ATTiny, then an MCU may end up being used to deal with a timing issue, but it was added to integrate with ATX power supplies under the ATX specification, rather than "it works with what we have on hand".



Fair enough, though the latter sounds to me like "adding an MCU to cope with the problems of timing". The Sinclair QL did the same thing, with an 8049, which would be 1984ish (it was a bodge OTOMH) so it's certainly period useable. So really are the FPGAs which are just very grown  up user programmable ULA and specialist chips. It's the same idea ; put lots of complex circuitry in one chip rather than having a rats nest of wiring, albeit created differently.

But then you get back to the same problem. Do you really have a machine where you can understand how it works ? Does it have any educational value at all as hardware ? And how much of it are you just treating as "a black box which does stuff" ?

If you want to really understand how it works you'd be better of with Nand2Tetris or the Ben Eater computer. Or both.

BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

Change of product direction, good and bad news!

Post by BruceMcF »



On 9/26/2021 at 4:22 AM, paulscottrobson said:




Fair enough, though the latter sounds to me like "adding an MCU to cope with the problems of timing". The Sinclair QL did the same thing, with an 8049, which would be 1984ish (it was a bodge OTOMH) so it's certainly period useable. So really are the FPGAs which are just very grown  up user programmable ULA and specialist chips. It's the same idea ; put lots of complex circuitry in one chip rather than having a rats nest of wiring, albeit created differently.



But then you get back to the same problem. Do you really have a machine where you can understand how it works ? Does it have any educational value at all as hardware ? And how much of it are you just treating as "a black box which does stuff" ?



If you want to really understand how it works you'd be better of with Nand2Tetris or the Ben Eater computer. Or both.



Pedantically (given that I'm an Econ professor/instructor by trade), it's adding MCU to cope with the problem of correctly powering up the board on an ATX power supply, and then using the MCU that was needed in any event to cope with problems of timing ... very much as the C128 had a Z80 because it was thought that running CP/M would be a checklist selling point but then the Z80 was used as the power-up processor so the C= key could be checked for to determine whether to come up in C64 or C128 mode.

It would be even [b]more[/b] like that if they would just commit to doing that, but they prefer to fix whatever issue is making reading the PS2 ports at 8MHz flaky ... which arguably might be for the reason below.

Whether they bit bang the PS2 with a VIA's or bit bang it with an ATTiny, it seems like a white box for anyone interested in how accessing a PS2 port works. The VIAs are preferable because it would be in 6502 machine code, but it's as white box as an pure open source Linux without any proprietary binary driver blobs, and with far fewer layers between a program calling CHARIN and the hardware talking to the PS2 keyboard to determine what character it being typed. It's far from the closed device driver code between my Gateway notebook and the characters I am seeing appear on my screen right now.

paulscottrobson
Posts: 305
Joined: Tue Sep 22, 2020 6:43 pm

Change of product direction, good and bad news!

Post by paulscottrobson »


I never was quite sure how it actually got keyboard input. I've only done it on Microcontrollers, Arduinos. There was a block on making a cheap serial terminal for a long time because people could get it generating video easily enough, and reading PS/2 was a standard library, but not at the same time, until the 1284 (?) had a seperate asynchronous clocked input. I always thought you had to poll it if you didn't use an Interrupt.

BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

Change of product direction, good and bad news!

Post by BruceMcF »



On 9/26/2021 at 10:35 AM, paulscottrobson said:




I never was quite sure how it actually got keyboard input. I've only done it on Microcontrollers, Arduinos. There was a block on making a cheap serial terminal for a long time because people could get it generating video easily enough, and reading PS/2 was a standard library, but not at the same time, until the 1284 (?) had a seperate asynchronous clocked input. I always thought you had to poll it if you didn't use an Interrupt.



If I understand, they poll the keyboard and mouse in alternate vertical blank intervals, so 30/sec.

Locked