6561 Initialisation

FD22 · Post by **FD22** » Tue Feb 14, 2012 8:32 am

For reasons best left unsaid at this point (too geeky, and needing a long post to go into the detail) I need to get a clear understanding of the behaviour of the 6561 (VIC) at power-on-reset. My hardware is boxed at the moment, and emulation (e.g. VICE) can't give me an accurate model.

Specifically:

1. During RESET, as the 6502 executes the VIC-20 initialisation code at $FD22, has the 6561 register block been hardware initialised to a known state - i.e. are the 16 registers at $9000-$900F pulled to zero? I know there is VIC initialisation code resident in the RESET path at $E5C3, but what about before this executes, such as during RAMTAS?

2. During RESET the VIC appears to display no picture - is this absence of image merely a result of all registers being zero (if the answer to the first question above is 'YES') resulting in just 'border' colour being drawn, or a lack of coherent signal from the chip due to the fact that it requires specific values (e.g. from $EDE4) across certain registers before it can begin to generate sensible video timing signals?

My intent is to alter the 'border' colour very early in RESET so that the user sees a full green screen image as soon as power is on, and this would then be replaced by the regular VIC-20 screen layout as usual once RAMTAS etc. are complete - or a red screen if some part of initialisation failed. I'm writing space-and-time-critical code, so if I can avoid initialising 15 VIC registers for no reason, or if necessary just initialise a few with specific values to enable signal generation, then it'll save me around 10 bytes and 100+ cycles.

FD22 · Post by **FD22** » Mon Feb 27, 2012 7:34 pm

Well this works in VICE, but I'd really like to know how a real 6561 behaves during POST. No-one here got any ideas?

Witzo · Post by **Witzo** » Tue Feb 28, 2012 12:10 pm

I read this with interest and curiosity, and admit I have not the faintest idea.
However, it sounds like you're doing a modern-day application of the VIC20 and hope it will succeed and that you can share your invention with us.

FD22 · Post by **FD22** » Thu Mar 01, 2012 5:00 pm

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/

Post by **Jeff-20** » Thu Mar 01, 2012 9:58 pm

The idea of a "new os rom" is fascinating. I've always thought about making small changes to BASIC, but a whole new rom is breathtaking.

matsondawson · Post by **matsondawson** » Fri Mar 02, 2012 3:19 am

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

orion70 · Post by **orion70** » Fri Mar 02, 2012 4:53 am

BTW, has anyone ever tried the VIC (simplified version of?) Fortran on cartridge?

Mike · Post by **Mike** » Fri Mar 02, 2012 7:13 am

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

I'm pretty sure you meant FORTH.

Leeeeee · Post by **Leeeeee** » Fri Mar 02, 2012 7:15 am

There's a FORTRAN cartridge?

Lee.

orion70 · Post by **orion70** » Fri Mar 02, 2012 7:34 am

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

Kweepa · Post by **Kweepa** » Fri Mar 02, 2012 8:32 am

I'm not sure why you didn't think we'd be interested!
Fascinating stuff.
I'll be watching this one!

TLovskog · Post by **TLovskog** » Fri Mar 02, 2012 10:36 am

I concur, this was a very interesting project. One of the few blogs that is interesting to follow. Very well and cool written.

Keep up the good work!

I also 100% can recognize me in your unconditional fondness of the VIC20 and 6502. I also grew up with that.

A question. Since you are rewriting the whole KERNAL and BASIC and also need to swap the ROMs physically. Have you considered swapping the CPU to the 65C02 and make use of it's improved instruction set.

FD22 · Post by **FD22** » Fri Mar 02, 2012 12:35 pm

orion70 wrote: 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 · Post by **Mike** » Fri Mar 02, 2012 3:20 pm

FD22 wrote: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 · Post by **FD22** » Fri Mar 02, 2012 4:03 pm

Mike wrote: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.