Jump to content

paulscottrobson

Members
  • Content Count

    93
  • Joined

  • Last visited

  • Days Won

    1

paulscottrobson last won the day on November 28 2020

paulscottrobson had the most liked content!

Community Reputation

34 Excellent

1 Follower

Recent Profile Visitors

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

  1. It's too eccentric. I've cannibalised some of the bits into something closer to a normal BASIC. https://github.com/paulscottrobson/6502-basic . It's modular so you can basically add and remove whole chunks as you like, and it's also designed to run in paged memory. So far : 32 bit integer and string types (hooks for floating point) long variable names. Integer and string functions and operators, BBC Basic style indirection. While/Repeat/For/Multilevel Ifs Procedures Locals/Parameters under development (at the moment they don't unstack ...) Outstanding: Inline assembler (can probably pinch most of this from atomic basic) Arrays Tokenising / Detokenising stuff (at the moment the tokeniser is in Python) X16 specific stuff.
  2. It's fairly easy unless you start wanting to muck around with the system stacks and so on. When I was a kid I had an MZ80K which came with Basic on tape, I remember hacking it so it had all sorts of stuff (including a Z80 assembler in line !) but that was pretty much entirely done by extending the keyword table and vector table and relying on an <evaluate> call
  3. This is a UK machine I had the Memotech MTX. I had some disk drives for it as well. It's all solid metal case, so it weighed a ton. In many ways it was a MSX type machine - Z80 + RAM + TMS9918, though it wasn't actually MSX compatible, and most of the games were ports from similar machines. It had plenty of RAM though, mine had 64k, and banked ROM, which included a sort of Hypercard type program, a fairly advanced machine code monitor, and oddest of all, a BASIC which took inline assembler, but it didn't work like the BBC ones, it was more like an editor built into the BASIC itself. I also remember it had a cartridge that was supposed to run Spectrum programs ..... that never worked. I can't quite see how it would work.
  4. I had one of those. I worked on it for a while. Was working for this company in NL and they'd given me the original IBM PC to work on (the 4.77Mhz 8086 one), using interpreted BASIC. It was so slow .... it could keep up with the typing, let alone run anything.
  5. Absolutely. The problem is those three lines - inx ; inx ; jmp (code,x) are executed so much that obvious fixing (putting BMI in there) have a performance hit. It's the same thing with the stacks. If you use that jmp (code,x) as your core, then you still have two stacks, one is fairly efficient and the other isn't. You can have as many stacks as you want, yes, it just takes a fair amount of CPU cycles to do them.
  6. Indeed, my bad, they extended it further for the proto C65.
  7. No, they aren't. There's character out, character in, possibly a seperate line in, and save and load files (and sometimes streams of data). The vast majority of the code is the same. MS Basic does not normally have features for manipulating those in any manner whatsoever.
  8. It would take about a week's work to write one. This one for example https://github.com/paulscottrobson/atomic-basic is an extended version of the Atom BASIC ; 32 bit integer only with 'C' style strings, so it's a bit experimental (it was meant to be), but it has a working interpreter with a built in 65C02 assembler, an idea I've always liked. No list or tokeniser yet, but that's straightforward (there's a Python script that tokenises it and then the run time takes over). Of course you could build a pick and mix easily enough, where different bits could be added or removed as you wanted, so for example have no floats or strings or whatever, different keywords for different systems. Then you can just add bits as you want ; interface to the X16 Kernel routines for drawing, some SPRITE commands, that sort of thing. You do run out of spaces, though there are paging ways round that it's a bit messy.
  9. MS BASIC, almost all of them, is designed to run on any 6502 hardware. There is almost no hardware specific stuff.
  10. I had a couple of the "springies" types which I think were rebadged Radio Shack ones. Looking at it with the benefit of hindsight two similar things were probably more important. I remember having a kit that did electrical experiments rather than electronics when I was about 9 or so, and that taught me a lot because it had 'proper' electronics rather than just building to a pattern, stuff about current and serial parallel resistors, even though the results were less exciting on paper. The other thing is the Ladybird book "How to make a Transistor Radio" https://www.petervis.com/Radios/making-a-transistor-radio-ladybird-book/making-a-transistor-radio-ladybird-book.html though I never did get the regenerative circuit to work. I always fancied rebuilding it though the parts are very hard to get. People make fun of Ladybird books these days but it's a quite astonishing book given that it's aimed at children. It's a microcosm of the X16 concept. The arrival of the ZN414 meant radio design was much easier (and a barrage of radios in things like matchboxes and tictac cases, but with one of those designs you don't have much idea what's going on underneath)
  11. Software almost always went for the lowest common denominator though. Some Spectrum games used the extra memory to save on loading, used the AY chip for sound as an alternative, but I don't know if there was ever a machine that wouldn't run on the basic 48k machine. There were a few 16k games at the start, most famously JetPac perhaps. Problem is, once you produced something that had to have some upgrade you limited the market. The ZX80/ZX81/Vic20 did have games that only ran with expansion, but only because the default had so little.
  12. Apart from issues with its copyright, Sweet16 is great (as is most of the stuff Woz does), and it'd make a pretty good runtime. The only problem with it is that its 10 times slower than the assembler equivalent. Woz was amazing at making something out of nothing - Apple colour, the disk drive and so on, but a 6502 is still a 6502. The UCSD P-System has the same problem but its worse.
  13. I don't have a problem with cross development, and I wrote a transpiler professionally thirty years ago (which could do way more complex things and had to generated readable editable code) for exactly the same reasons. Difficult to measure the exact speed up, but on a similar project French colleagues were doing 2 reports a day and I could do one in about half an hour :) Cross development on an X16 is entirely sensible for the same reasons that it was when people were developing professionally for C64s and Sinclair Spectrums, after the first year or so, anyway. I've written a couple of X16 compilers which I'm not happy with for various reasons, mostly connected with having to downgrade the compiler to fit the system. My 'opinion' is that almost nobody at all will program the system in any other way. I'm not actually convinced anyone will program it at all like the old cross dev systems where there was a physical download connection. I think they'll develop it on the emulator, and occasionally run it on the system.
  14. The problem with it is if you just crossdev you get away from the original point of the design - I thought - to replicate the learning environment we had on our Spectrums/C64/BBC Micros etc without the downsides (mostly storage before disk drives). You might as well design a console type design.
  15. It's not just that. It's too slow, or too limited to run a runtime - you either lose too much CPU time in the runtime, or if you generate 6502 code it's horribly inefficient for many things. It's fast enough but you just use too many bytes doing simple things like 16 bit arithmetic, adding two non zero page is 19 bytes and even for zero page its 13 bytes. For some things like say Action! it didn't matter too much because much of the data was 8 bit, which a 6502 is more efficient with. But because of the expansion of VERA there's a lot of 16 bit data in there. There are several excellent modern compilers which attack the CPU in various ways, but the core problem really is still there. So Michael extended the OS with all these 16 bit registers, which I can see the rationale behind, but it just isn't a 16 bit machine.
×
×
  • Create New...

Important Information

Please review our Terms of Use