Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


paulscottrobson last won the day on November 28

paulscottrobson had the most liked content!

Community Reputation

9 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Might be an interesting challenge to update the display fast enough.
  2. Would seem so. Though the M65 is almost entirely FPGA - you can make one out of a Nexsys A7 that is identical except for some of the connectors. As you can with Vera, but not of course with anything on the main board.
  3. In the latest Vera docs there are 6 (I think) "classic" sound channels which generate the usual square waves and noise and a dedicated PCM channel. Whether this is still the case or not I do not know, but it does rather beg the question of whether there's a point in putting a real chip on the board, I don't think sound has ever been considered. "Much of a muchness" is a British expression meaning not too different. Mega65 has twin SIDs, it would have to have one as it emulated the C64 as well and it also has a couple of D/A channels. So it's sound is better but I suspect in practice it won't make too much difference. The ability of the SID to be able to be tweaked to produced clever effects is negated by just being able to play any recorded sound you like.
  4. The M65 has other options than Sprites. It's probably more powerful, but at present harder to access. There is almost zero chance of it being taken up for commercial development. It will be like the other Retrosystems and real retro systems, there will be some games produced like say https://www.rustypixels.uk , Planet X2 is another example, but mostly it will be people's own work, a mixture of reboots of old games and hack improvements versions of classic games (perhaps), which won't apply to the X16. This doesn't mean the games won't be any good, they'll be the usual mix.
  5. I've heard very good things about the Vic20 manual as a starter. As regards things like Assembly, there are countless books out there, many of which will be free to download, and quite a few online courses as well. People still like to program the C64. Whilst much is different, it is at a detail level, conceptually it is very similar and learning a C64 or similar will get you a long way down the road.
  6. There is one minor upside. There are some games - Elite was demoed by someone on the M65, have seen similar on the Next - Driller is another good example, the 3D adventure that the processor couldn't really cope with. These now run at a decent speed. Having said that , most emulators allow you to hack the emulated CPU speed anyway
  7. I was suggesting doing both If you work through Ben Eater's 6502 course (I've only skimmed it) you won't have much of a computer but you'll learn a heck of a lot. Then progress to a machine like the X16 and you should be able to see the links between what you learnt on the first course and what the X16 is doing. Though you'd have to view Vera as a "magic box" I think. That's basically what I did, I started with an SC/MP trainer board and then had one of chicklet key PETs. I'm very glad I didn't start by using C# or Java and never dropping down. The Mega65 isn't that different to the CX16, the documentation isn't very clear is half the problem. In some ways it's simpler, because you can write to screen memory in the same way you do on a C64/PET/VIC. In some ways it's more complex - DMA and stuff. Pricewise .... I suspect more M65 than SpecNext levels.
  8. C doesn't really fit a 6502. It's a byte orientated CPU. Adding 2 16 bit words takes 19 bytes. There's no way round it that doesn't eat CPU cycles, even clever allocation and deallocation of zero page isn't that effective. So : do as much byte work as humanly possible try to avoid stack frames - no parameters, locals. Make your locals static. try and use zero page.
  9. But is it ? I agree with you on the root concepts idea - I've always said people should do something like program a PIC16C84 or a C64 or something like that so they know at root what's going on (some PHP programmer told me "Boolean Algebra's not a thing" any more ...). Not sure we're there. Might be better off doing the Ben Eater design , or something similar to do the basic stuff.
  10. Oh it's good. There's several 6502 languages that are similar (Prog8 for example) but they all really have the same problem. If you work in 16 bits the 6502 isn't very good - it takes up a lot of memory. I did some fiddling this morning and function calls are limited, though I haven't worked exactly how yet. You can't write PRINTC(DOUBLE(42)) for example. I suspect it will only allow function calls at the lowest level of precedence, but if you have an intermediate result stacked it won't work.
  11. Nice demo of what can be done in pure BASIC. It's a fairly brutal time limitation, 40 seconds to do the warm up level
  12. For CARD and INT (it has signed and unsigned types) its generating straight 6502 assembler, which is very inefficient in memory usage. (Bytes are way better). The function calls in Action I never did check. Procedures use AXY then memory statically to pass in parameters which are then copied into the static locals. This doesn't work for functions because as you say there is no stack apart from the return addresses and you create problems with functions calling other functions ..... recursion works in Action! I think except that you have to do your own local stack, locals being static. The manual doesn't specify any limitations on parameters, but if you don't have them they have to go somewhere. You also are in the middle of an evaluation with a function call, so that state has to be preserved as well, and I got the impression it uses registers for precedence levels (it's a while since I looked at the binary). It could of course shove all this lot on the stack. You could have an alternate set for in function expression evaluation but then you can't nest them. There may of course be some smart alec way of doing it I haven't fathomed, but Action!, while it is a solid piece of work is not particularly ingenious.
  13. I have one myself as have countless others. It's faster than the CX16 and costs a tenner. But there is one important pro that none of the others have, except for three ; a large potential user base - the three are the Spectrum Next, the Mega 65, and the Commander X16. (there are others that have smaller bases, the Gigatron, RC2014, Zx Uno perhaps and so on). Without that user base you don't have software, an eco system, and without that you have another in the long list of machines that were technically excellent but you couldn't do much with. In the 1980s when I was a lad there were many of them. Neither the Speccy or the C64 is a particularly good design, the aim being to maximise profit for minimum design effort. But there were so many of them people worked round their limitations to often spectacular results. In some ways it's an advantage. Without the option of flashy graphics or sound on a Spectrum, people tried new game ideas instead.
  14. Graphically they aren't too far apart, in terms of the tile maps and so on. This isn't surprising as they are both developments of C64/C65. The Mega65 is probably more powerful but a bit messier and confusing. The X16 is relatively simple, you can figure it out mostly straight off (this isn't a criticism). The Mega65 does not have the CX16's problem of the limiting bridge between the processor and the graphic memory. The CX16 has more sprites but less options for replacing them in other ways. There is one huge difference. (And yes I do know why, authenticity). The 6502 in the Mega65 has several changes. One is to widen the address bus so it can access 24 bit addresses (though it is still basically a 6502). Another is the addition of some 32 bit data operations. The last is the clock speed ; it runs at 48Mhz (not sure but about this but it's this sort of order). This is fast enough to put it in the same box as the ARM system David reviewed a while back ; you can write proper retro style games without having to write in Assembler, and you can run a fast enough P-Code system. Having done it on my own system I've a pretty good idea how much "poke" you need to make it work, and the CX16 doesn't quite have it (by a factor of 2-3) without big chunks of assembler. It doesn't bother me writing it, but it handicaps the beginners. The more the merrier though, why not Robotron in BASIC. Both have similar systems software, basically bodging the C64/C65 kernel and BASIC ROM to provide limited support for the extended facilities and interface to SDCards rather than cassette tape. Sound is much of a muchness. For some reason there's a floppy on the prototype (can you buy them any more ?) The other difference is that the M65 has a huge software base, though to be honest this doesn't really matter. If you just want to play Game X on the C64, you can either buy that Mini64 gadget, or simply run it on VICE or similar. It's easier and simpler. If you want to play a game, you want to play a game. Backwards compatibility is nice but overrated IMO, applies to the Spectrum Next as well. They aren't really that different. The last time I looked, the FPGA was doing all the graphics, the PCM, at least some of the audio channels and the SDCard I/O. This leaves you with the CPU, RAM and ROM (which are external on the M65 I think), possibly some audio channels, and a PIA/VIA for interfacing (the keyboard port may be on the FPGA now, I'm not sure). So basically the difference is that the M65 has a CPU in the FPGA and the CX16 doesn't. And the prototype M65 batch is 1000 Euros. Not sure what CX16 is going tobe, other than way more than Dave's £ 30-40 estimate.
  15. I've had a look at Action. It's pretty good and makes some obvious saves (e.g. static locals rather than a stack). It generates pretty good code, but it still has the same problems as any other 6502 compiled language, 16 bit inefficiency. Having said that, with some work implementing cross bank calls (primarily) its okay. It does run natively on the machine, but I'm unconvinced this is actually useful, as it's much easier to cross develop and it would be much easier to produce an Action compatible in Python than 6502 code. It's actually simpler than it initially looks. I suspect there are some limitations on function calls (because I don't think it uses a stack for evaluation) which I never quite figured out.
  • Create New...

Important Information

Please review our Terms of Use