Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by paulscottrobson

  1. I'm a big fan of the SC/MP but I wouldn't use it as the basis for anything designed to be used now.
  2. It's very similar to the CX16 design. (with a few advantages ; it's faster, no paging and so on). It's just engineered in a coherent fashion. And it exists without burning 5 figures.
  3. Probably less than that, though shipping to Canada you never know. The answer to your question is "it isn't done yet", but likely not, significantly, more complex than Basic V. The problem is it's essentially the same product as the X16 Modern version of classic CPU (though the eZ80 is significantly faster and has a 24 bit address space, the instruction set is an expanded Z80 (e.g. you can do things like LD DE,(HL) )) RAM about the same 512M on the basic model. Graphics and Audio handled by a seperate modern part via a fast serial link. The design of the link is more client/server I think than "Poking bitmaps" (though you probably will be able to poke bitmaps), so probably commands to draw lines/polygons etc. rather than bit tweaking. I think the graphics is based on FabGL though is likely to be extended. VGA/PS2/SDCard connector. Differences: There's no ROM other than that on the eZ80 and initially it will be an X8 design viz. boot off the SDRAM card The "VERA" equivalent is an ESP32 not an FPGA. It is less practical to build as its entirely SMT though it is open source (I think) Uses a cheap PSRAM chip to provide storage for graphics/audio stuff (8Mb I think) The eZ80 has a 24 bit address space - HL DE etc. register pairs are now 24 bits wide (it can be put into Z80 compatibiilty mode) It's only 6 bit colour. No "real" audio chip. Direct code load port. USB port. Don't know flexible it is, e.g. could you plug a mouse or gamepad in ? There's a reasonable question of "why not use a Raspberry PI" or similar, which is perfectly valid. The same criticism could be made of the Commander X16, and pretty much all the other retrocomputer projects and was made repeatedly at the start of the X16 project. Does it give you something better ? Not really, but none of them do, save for programming on a modern version of an 8 bit CPU.
  4. It’s a client server model. Effectively a 30Mhzish z80 equivalent (its pipelined) but extended, flat 24 bit address space. 512M of RAM. I/O done by an Esp32 via a serial port, so it isn’t going to be a direct bitmap access, likely to operate at next level up. Serial PSRAM for graphics storage. Likely cost sub $100 The ez80 is a z80 with 24 bit address pairs. Takes a little getting used to, because you can forget this ! It can do a compatible z80, bit like the 65816.
  5. Is there no documentation for the board ? Mine had a fair bit - okay mostly in Chinese, but you could figure out the board wiring from the circuit diagrams, it was enough.
  6. Yep. You could probably build an X16 on it ...... they're pricey now though (Unless Matt is Australian). I have an earlier generation board and it was more like half that. They're usually figurable because circuit diagrams are fairly universal and the parts are standard parts. However, the documentation is in Chinese
  7. I still think they're working out basic design issues. I don't think it's reached a "we can start building tomorrow if we get the bits". Next is Open, so there are already alternate Next PCBs without a case e.g. https://www.vintageisthenewold.com/retroshop-announces-the-first-zx-spectrum-next-clone-board Going to be like the M65 ; you can have a cheap one or an expensive one with all the gimmicks/special case etc.
  8. I think you'll have to stand in line for the Mega65 and X16 Though it is possible they may eventually produce a cheap Mega65 without all the fluff.
  9. Lean is basically a macroassembler that *only* does macros. So every action you need is defined as a macro (and some structure, and procedures are provided). So you define your own assembler instructions and register and lean converts it into the target CPU. Lean as implemented chooses something close to the 6502 (e.g. treating XA as a faux 16 bit register) for efficiency. Much of it is 1:1 so y++ maps to iny for example.
  10. Yes. I don't know for the current design, but AFAIK the Vic20 and C64 do not use NMI - it appears to be connected to RESTORE. An NMI would not be suitable for keyboard polling per se perhaps, there may be some hardware accesses that it would mess up, but you could make it an IRQ with a pull up transistor or something. There are pretty stable i2c libraries and ps/2 setups for AVR chips, so it shouldn't be difficult to make what is effectively an i2c keyboard.
  11. Well .... this board seems to have more microcontrollers than Digikey these days.
  12. Why not an ESP32 ; then you have Wifi, i2c and a well tested PS/2 interface all in for a few quid. Then move the sound samples out of VERA (which doesn't have the memory) into an ESP32 (which does) and use that to generate audio (and you might as well put the standard waveforms there as well). Some sort of standard API so you could replace it if necessary. The i2c interface can be used for expansion as well.
  13. PS/2 devices can behave very differently. And many are put through PS/2->USB converters. Generally it seems the case that cheap and basic keyboards are more reliable than those with lots of gadgets, bluetooth and so on. There are three solutions to this. Connect the clock to the interrupt. You could maybe connected to NMI except you'd want to be able to gate it for some hardware, effectively another IRQ. Have some sort of clocked shift register design or an CPLD/FPGA connection that does the work for you Have a microcontroller do it similarly. Polling is a *bad* idea. There've been Microterminals built around Atmel AVRs for years - I built a couple of 1802 based clones round the 8515, but they were matrix keyboards like the C64/Spectrum and you can address them how you like when you like. Nobody managed to get display and PS/2 working together - they'd been working apart soundly for ages - until the AVR1284 I think, which has some clockable register that does serial input or something, can't recall. You then started getting projects like this https://www.instructables.com/Single-Chip-AVR-BASIC-Computer/ which were delayed by this limitation unless you wanted something that worked like a ZX80 and blinked.
  14. How about we have a microcontroller for every single key on the keyboard and every function on the circuit board. Think how fast it will go then. Or we could stop pretending.
  15. The joke is that most of them are the same. The odd ones are the MM57100 (the one with three bats at the start, an early colour variant that was in 2 or 3 models) and some of the ones at the end, which are the later one chip devices in a "cartridge" I remember years ago Elektor magazine publishing a Pong design, no scoring (done by ball bearings on an indented case I think) out of op amps and TTL and so on and it went on for ever, something like 40 standard ICs I think and it just played straight pong, two bats and a ball. Then GI launched the AY-3-8500. This commoditised them - if you had one, especially outside the US, it was likely a 3-8500 based console - that did everything for you. 4 (or 6 if you added the shooting) games, different sizes and speeds, on screen scoring. Any manufacturer could produce them and did. Cyber's model possibly a 3-8500. It looks like one, with the dashed lines, and it's not a well known make I think, but I've never heard of a model with three paddles on one side and two on the other, so it's possible this is an artefact of being photographed or converted from some other format ? I remember getting our first one, oddly it didn't have slider or rotary potentiometers but rollers attached the front of the case with the axes parallel to the fronts that you rolled between your thumb and first finger. But it was great fun.
  16. No, because the output device is basically a slow serial teletype on screen. All you can do is push things out sequentially.
  17. I'd consider writing some C routines in assembler ; probably setWriteAddress writeByte and writeBlock methods. You could do it with byte pointers but given it's for a 6502 most efficient approach is to do it in 6502 assembler
  18. It's not really feasible. You could set aside a buffer of memory , write to that and copy it to the display, but it would be slow. Screen memory is accessed through an I/O port.
  19. I don't think it's speculative, a few do actually exist. All the serials are less than 200 I think, so this is probably a lower and upper bound on the numbers released. Maybe they were development kits ? Obviously the M65 is way more powerful, but it is (I think) backwards compatible.
  20. This is easy. Clock your 6502 at 50Hz, build in a 32 bit hardware multiplier (maybe), and have a BASIC which is optimised for speed. That is fast *enough*. If you had a BBC Micro style assembler built in to it, then that could do the heavy lifting when you need flat out speed. The other alternative is to cross compile on a PC and upload to the X16.
  21. The whole thing is utterly insane. If you want an authentic retro experience, expect the retro problems. The machines aren't that quick and the graphics aren't that great. There's a thing called the "Cerberus 2080". It's a twin 6502/Z80 machine that uses a couple of CPLDs to replace a wodge of TTL. Graphics are monochrome UDGs. If you want a kit, accessible hardware go for that sort of thing. Or one of the ZX81 or Spectrum clones maybe. Or just say s*d it and go down the Commodore X8 type route and push the CPU up as fast as it will go. Same route as the Spectrum Next, and the Mega 65. Something that's fairly technically close to the original idea, cheap to build and doesn't waste time on endless timing issues trying to glue things together. Over engineered solutions to problems created by ridiculous design decisions. Why do we have to have a pretend Vic20 ; what happened to the concept of it being educational. I'm an ex-teacher who started in 1985 and I'd have avoided Microsoft BASIC *then*. Now it should be viewed as a form of child abuse. It's *way* easier to rewrite the Kernel and BASIC than it is to continually try to hack it to get something vaguely acceptable. The code is awful, incomprehensible and chaotic. And we're still stuck with the bizarre filesystem concepts that originate in the old PET IEEE488 design, so presumably half a dozen ancient typeins will work.
  22. You have a choice between very slow (psuedocode) or long winded (think of the 6502 code to add two 16 bit integers). Have a look at the code compilers generate ; Action, C, anything that outputs 6502 code. FORTH doesn't work well particularly ; few registers, one stack. Though jmp ($xxxx,X) has made it better. The best way of deving for the 6502 is to write the slow bits in a fairly compact p-code and the fast bits in raw assembler.
  23. Still have the problem that a 6502 is a very poor compiler target for *anything*.
  • Create New...

Important Information

Please review our Terms of Use