6561 Initialisation

[FD22]

Oops. Nope, there's a FORTH cartridge, but definitely not a FORTRAN one.

I had the Audiogenic FORTH cart back in the day. It was great - it came with a set of A5 pages stapled together containing an indecipherably cryptic set of instructions on how to use 'pages' (which I think referred to the editor), no FORTH instructions, and no guide to the keyboard controls it used to switch between functions. I gave up after about 3 days of trying to figure out how to work it, and it gathered dust forever after.

Thanks for the kind and encouraging words, everyone. To answer your questions, I'm going to be creating a hybrid BASIC/C-style language, which will actually convert the high-level code to raw 6502 on the fly (and back again when you type LIST). The idea is that programs will run fairly close to pure machine-code speeds, as they'll effectively be dynamically compiled.

And no, I'm not swapping the CPU for a 65C02 - it's a cool idea, but I really want to find out how hard I can push a stock 6502; plus, my homebrew project will be using a pair of them when I finally get the opportunity to build the hardware, so I have to stay within the original 6502 instruction set (including undocumented opcodes, natch ).

[Mike]

a hybrid BASIC/C-style language, which will actually convert the high-level code to raw 6502 on the fly (and back again when you type LIST).

Yet another Quetzalcoatl or Tiny Basic Compiler? This time even proposed to be hosted on the VIC-20 itself and also doing compiles-on-the-fly?

In any case, such a language would have to provide good support for modern control flow structures, 32-bit values, strings and float values. Otherwise this isn't going to gain an edge over hybrid BASIC + ML programs.

[FD22]

Yet another Quetzalcoatl or Tiny Basic Compiler? This time even proposed to be hosted on the VIC-20 itself and also doing compiles-on-the-fly?

In any case, such a language would have to provide good support for modern control flow structures, 32-bit values, strings and float values. Otherwise this isn't going to gain an edge over hybrid BASIC + ML programs.

I'd say it was more akin to TBC than Quetzalcoatl, since it's not intended to do cross-compilation - it is, as you affirm from my earlier post, a native VIC-20-hosted dynamic compiler. And my intention isn't to create 'yet another' VIC-20 product - my opening post in the blog explains clearly that this is actually a project intended for a custom homebrew machine, but using the VIC as a software/concept design host. Which is why I didn't post about it here, except to ask the 656x question, until an interest was expressed - it's VIC Jim, but not as we know it.

And yes, the language design is already far enough along to support modern control flow structures (without, incidentally, any risk of stack-overflow), 8/16/32/64-bit integer and float, signed and unsigned numerics, strings limited only by memory size, arrays, jagged arrays, associative sets, hash tables, indexed and keyed dictionary structures, and strongly-typed primitives including Bit/Byte/Word/Long/Double, String, Array, Char, Float, Pointer, and Boolean. There is also an aggressive garbage-collector, optimiser, and what I call SAVE FINAL, which turns the dynamically-generated assembly into a fully dereferenced non-editable 'cooked' version of the code.

Whether anyone aside from me ever chooses to use it, I do not predict - indeed, I'm designing it for use in a different computer and I'd be surprised if anyone else ever used it. But it'll work on the VIC-20, and if nothing else it's giving me an opportunity to write some nice 6502 and talk about it in a blog. And thus, it suffices.

[Mike]

I'd say it was more akin to TBC than Quetzalcoatl, since it's not intended to do cross-compilation

CurtisP's TCB also isn't hosted on the VIC-20, it's a cross-compiler as well.

the language design is already far enough along to support [...]

Oh my goodness, you're hauling out the big guns here!

You can design a language as you want, whether a 6502 + 64K RAM/ROM + I/O are a feasible platform to implement it, is truly another matter. I doubt you had that specification in mind in those days when you dreamt up your 'perfect' computer.

As far as the current state of implementation is concerned, I don't see much more than a memory test (do you test the correct function of all address lines, for example?) and whatever might go beyond that is at best hard to judge for me - given that you didn't publish/release much VIC-20 related software or hardware since you registered here in Denial.

In any case, you went public with your ideas, and maybe the best chances to realise your dream in some way could be to turn it into a community project, even if the result might turn out slightly different from what you originally thought.

Greetings,

Michael

[FD22]

Well, you have me at a disadvantage - I'm not familiar with either TBC or Quetzalcoatl, and haven't studied either more deeply than a quick look at the links you posted. I guess my point applies to both, if they're both cross-compilers; the VIC++ language will dynamically compile in-situ, rather than from another host to the target.

I kind of bristled at the implication that I was talking out of my hat when I mentioned the language concept - so, yeah, big guns fired. The language actually came first, as it's something I've been working on (on paper) for a long time and then only recently decided that to make it work as designed I'd need to re-jig a whole bunch of BASIC logic, and that would need a goodly amount of KERNAL changes too. So the language project amalgamated with the homebrew hardware project to kill two birds with one stone. None of this compares in the slightest with any ideas I had 30 years ago - those were fantasy concepts without the foundation of hard-earned practical, professional experience to back them up.

And yes, the work is in the early stages of realisation, so I'm blogging as I go along - which is why the blog has concentrated on initialisation so far. It's early days - there's not much to see yet, but what there is works. I have deliberately not implemented anything more sophisticated than a simple sticky-bit test, because as I point out one of the key design goals for initialisation is to be faster than the original ROM whilst providing at least the same functionality (somewhat more, in fact). So I don't do a deeper address-line test, or even fully implement the Walking Bit test which is only partially used in the original ROM - the boot code isn't intended to be a full-blown diagnostic, just a simple verification that RAM appears to be working as expected, and some extra bells and whistles beyond the basic test logic in the original. As a result of that, and of very careful cycle-timing and algorithm choice, POST time in the new ROM is, worst-case, about 33% faster than the stock ROM.

I'm not sure what my Denial post history has to do with anything, though...? I didn't 'go public' for approbation or critique, but because someone here expressed an interest after I asked a hardware-related question. I'm not looking for acclaim from anyone - if it's of interest, great, and if not then I guess I'll be the only one reading the blog.

Now, I must concentrate - I'm just writing the skeleton of the IRQ handler and it's first task, a countdown TOD clock.

[matsondawson]

Could do a Fortran Vic-20, I hear Fortran is pretty fast vs Basic.

Whoops sorry, I meant Forth.

[rhurst]

Nicely written blog (for the rest of us) given your first-person insights in examining the intricacies. I did not see any mention of how you are going to test code, or perhaps you had in an earlier blog post? Are you making a ROM image to use in VICE xvic, with its SAVE FINAL for burning later?

[FD22]

Yep, precisely - earlier posts talk about how the code is generated and tested by telling XVIC to load the new ROM images instead of the Commodore ones.

SAVE FINAL is a proposed command for the new language, which performs a chunk of optimisation on the user code before saving it - those changes are non-reversible 'fixtures' to the body of the code, folding elements from the symbol table into the logic and dereferencing variables. The code becomes faster, but non-editable in its' high-level form (you could still edit the assembly, of course).

[TLovskog]

Thanks for another blogpost. I really look forward to following this interesting project.

[Witzo]

I wasn't sure whether what I'm doing would be of particular interest here, because it's something to do with the VIC-20, but only in the sense that the VIC is the basis for it.

Have a look, if you fancy it - I won't be upset if you don't think much of it.

http://vicpp.blogspot.com/

I think highly of this. It seems to be a project to prove what can be got out of the hardware, and put in the original ROM space, when everything is maximized.
It will show off what was already possible in 1982, but maybe just not entirely achieved at the time.

[FD22]

Still working on VIC++. Had a few months off, back in the saddle again now.

Latest post talks about getting the 6502 undocumented opcode LAX Immediate (unstable, except for LAX #$00) working in DASM via a little macro. Just in case anyone's interested.

[TLovskog]

Glad it is back. Actually have missed it. It is interresting and very good written, with a nice touch.