VIC-I addressing (newbie) question

Modding and Technical Issues

Moderator: Moderators

User avatar
lgb
Vic 20 Drifter
Posts: 25
Joined: Tue Apr 26, 2016 8:10 am
Website: http://lgb.hu/
Location: Hungary
Occupation: System engineer

Re: VIC-I addressing (newbie) question

Post by lgb »

First of all, thanks for you message!
The main issue the developers of the VIC-20 originally faced, when putting 6502 and VIC-I into one machine was the 6502 could not tri-state its address bus. The VIC-I, on the other hand, plays nice.
Yes, as far as I know, 6510 basically more than 6502 with this feature (well, and also a 6 bit I/O port, on address 0/1 for data and direction). I'm not so smart with modern CMOS parts from WDC, but as far as I see, 65C816 wouldn't have the problem with the tri-state stuff. Also, it's interesting that though 65C02 is also available nowadays, it is simply not worth, in my opinion. Ie, the price is almost the same, and it seems 65C816 (in emulation mode) behaves like 6502 more, than the 65C02 itself ... The only problem with 65C816 - well, as far as I remember - that in every PHI1 state it emits the bank number on data bus (meant for the next PHI2 access as the high 8 bits of address besides of A0-A15 then, thus the 16Mbyte address space), which needs to be latched externally during PHI1 and shouldn't be allowed to "go" onto the main bus as it would cause bus conflict with eg VIC-I. My first idea was to remove the 6502 from VIC-20, and create a board with pins on its back, to be able to be inserted instead of the 6502. It should contain the glue logic, different pins, etc, whatever, and maybe also dedicated SRAM only available privately for the CPU itself. The SRAM on the VIC20 board would be only shared between CPU and VIC-I (btw, VIAs can be also bought - in CMOS version - capable of running even on 14Mhz clock - or higher as with 65C816 it's told that 14MHz is somewhat a "paper limit" only ... so VIAs - in theory - can be also replaced to modern parts, and the "new CPU" is free to access them in "fast mode" too ... anyway they are fed with the original clock in VIC20 mode, so it wouldn't introduce an incompatibility because of the different timer meanings etc then). I am not sure though, that the original "famous" bug of VIAs are fixed in the CMOS version which made the hardware shifting impossible on the serial IEC bus, by the way (it would be nice to allow to use fast/burst IEC between a modified VIC20 - with newer VIAs - and an 1570/71 which supports that feature with the C128, but it should work with everything has the bug-free shifting features what was the problematic parts of the original VIAs - again and always: as far as I know!).

About the RMW instructions: as far as I can see, the major compatibility problem with 4502/4510 (well, 65CE02 ... as for the "CPU core" name) would be used in the Commodore 65, that it does not write twice, and this feature is often used in softwares with I/O registers. I am not sure if it's a value for VIC20, or the 65C02 or 65C816 also includes this "problem" which would create incompatibility with the original 6502 though.

By the way, I always feel that 65xx handles stack and zero page (ok, "base page" more, if it can be relocated, it's not "zero" anymore) as a second class citizen. What I mean here, especially if you have plans to create a true multitasking OS (well, I have plan like this ...), it would be important to have own stack/zero page per processes. With 65C816 you can breathe, that you have relocatable stack/zero page, how nice. But again, like with the original 6502, these stuffs - again - meant not to be "important" ie, the CPU can address 16Mbyte of memory space, but still, zero page and stack can be in bank 0 (first 64K) only, so again the same problem, that it's kinda restricted :( Well, of course the situation is much better, I haven't told it's not :)

I'm not so sure about the original 6502. I guess it won't release the bus (as with high-Z state) even during the PHI1, that's why there are the LS buffers in VIC-20 to isolate from the bus?

Anyway. I think, the first try can be *only* to try to replace the 6502 with 65C816. Without any trick, more memory etc, and let's see if it works. Maybe almost only some wires needed and not so many active components. The bank number during PHI1 wouldn't be a problem, as the buffers isolates the CPU from the bus anyway during the PHI1. With only this project, we already able to utilize 65C816 extra features (even 16 bit mode, etc), though on the original clock only, restricted to 64Kbyte address space, etc. But softwares don't use illegal opcodes, including BASIC and KERNAL should work as nothing would happened ...
You see, even with a simple computer like the VIC-20, there's already some engineering involved to get two bus masters working together as team. A simpler redesign might be doable with todays means - with dual-ported RAM. In that case, VIC could simply access its RAM as it wanted, and the CPU just can do the same. Also, the CPU can operate with another clock, and as VIC only reads, there can't be any write-collisions. Only register accesses need extra arbitration logic, i.e. the CPU must stretch its access cycle and allow VIC to snoop on the address bus for its own address range.
Hehe, yeah. :) Dual-ported SRAM was in mind too, just I felt somewhat "cheating" like stuff :) But anyway. We need only 16K. Mapped in a way for the CPU as VIC-I on VIC20 (well, I would use dual port RAM also for character "ROM", and at least some can use to redefine the charset without the need of extra RAM ...), also VIC-I "should" see this dual ported RAM for the rest of space after the charset ROM (or "ROM") ie "behind" the I/O area etc (it's another thing that CPU should access it too, maybe switchable I/O space, or for the CPU the "hidden" SRAM can be mapped from $A000 (well, to be honest I am not so much interested in cartridges with the problem to conflict them ... my bad ...). And even more advanced (or already too advanced ...) solution would be to use 16K dual ported SRAM for VIC-I addressed exactly linearly, and a configurable way, where CPU "sees" this space, with - of course - the ability to use the same layout as on the VIC-20. So in nutshell: though dual ported memory seems to be a "cheat", it would handle the situation nicely to go CPU "fast" on every memory accesses! The only problem would be the I/O accessing then. I have not idea though the availability of dual ported SRAMs, even nowadays they are seems to be quite expensive (well, I measure this with my almost non-existing budget for hobbies ...). But 16K wouldn't be too expensive, I guess (as far as I remember, 64K was quite expensive when I checked last for another project ...). The other limiting factor is my soldering/board making abilities, which is kinda low :D I fear of SMD parts a bit, to be honest :) Especially with the usual strip board / etc designs, you see :) And yes, the 4 bit colour RAM is still a question. As the VIC-I (afaik) like VIC-II has 12 bits data bus for real (with 4 bit wired to the SRAM only?) it's kinda interesting question too, that we may need 12 bits "wide" dual ported SRAM too, or two packages, etc? The colour SRAM can be smaller of course. 1K, or a bit more :) to allow to "switch" between for some kind of tricks I don't know about really, maybe it's useful for something, I have no idea, I also lame with C64 advanced techniques like FLI, etc ... And also, with dual ported RAM, I can also build my original idea ie using a Commodore plus/4's TED (or even with VIC-II, etc) without worrying on TED accesses using switched clock and the "GATE IN" pin of the 6502 variant used there (honestly, I still don't know what that pin does exactly ...) etc. The reason I thought about VIC20 that it can be done simply, without the need of dual ported memory.

Yes, of course, a SID is wanted too, just in case :D And it is also "slow" I/O but it does not matter too much, as VIC-I registers needs that too (as I've written before, the same may be not true for VIAs, if they are replaced to modern 65C22 parts as well ...). Another "odd" idea is to include a VDC as well as an I/O :-P So basically you would have 80 columns modes as well, if someone really needs it. Maybe nice way to try to port GEOS for the VIC-20, as VIC-I is sadly too "little" for that :-/ It's kind of "at the border already" feeling, as it wouldn't be a VIC-20 too much anymore at this point. But as I've said, maybe I would do better to create something new which has "VIC-20 compatibility mode" as well, rather than saying to expand a VIC-20. But the border is faint between these two notions, I must say ...

Btw, about the SID: I am not sure how it's out of specification (?), to include SID in VIC20, as the clock is somewhat higher than in a C64. Maybe it wouldn't be a problem (that it works) but the oscillator frequencies would be a bit out of the original values, compared to a C64, I think. My other idea was to use the OPL2 chip (eg, found in AdLib too, YM3812, if I remember correctly of the name). It wouldn't be a great surprise, as with C64 at least, the SFX sound expander cartridge used that (well, OPL1, just many people - ? - replaced that with OPL2). I've even written a C64 program which can play back OPL2 register events (recorded with DOSBOX eg from old PC games ....) on a C64. Though I could only test in VICE, as I don't have a real SFX cartridge (but it wouldn't be build one hard, as many AdLib and older SoundBlaster cards includes it with the right DAC chip alongside ...). Here is some kind of "demo" just in case, if you're interested, btw:

https://www.youtube.com/watch?v=umiL62CPObg
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: VIC-I addressing (newbie) question

Post by Mike »

That thing beforehand:
lgb wrote:I'm not so sure about the original 6502. I guess it won't release the [address] bus (as with high-Z state) even during the PHI1, that's why there are the [245] buffers in VIC-20 to isolate from the bus?
... already answered here. :wink:
Mike wrote:The main issue the developers of the VIC-20 originally faced, when putting 6502 and VIC-I into one machine was the 6502 could not tri-state its address bus. The VIC-I, on the other hand, plays nice.
... and that's the reason, why the 6510 has this feature built-in.

A good deal of your ideas, even up to the point going for an entirely new mainboard was discussed in 2011 in the thread 'Thinking of a SuperCPU VIC', even including some nice timing diagrams ( :lol: ), so that might give an interesting read for you.
I am not sure though, that the original "famous" bug of VIAs are fixed in the CMOS version which made the hardware shifting impossible on the serial IEC bus, by the way
Not entirely impossible, but it would have required a lot of fix-up code, where the place wasn't available for in the VIC-20 ROM. Instead the engineers decided to re-implement the protocol bit-banging in software. :(
About the RMW instructions: [later 65xx-CPUs do] not write twice, and this feature is often used in softwares with I/O registers. I am not sure if it's a value for VIC20, [...]
You can count about *every* strange feature has been used at some place.
By the way, I always feel that 65xx handles stack and zero page (ok, "base page" more, if it can be relocated, it's not "zero" anymore) as a second class citizen. What I mean here, especially if you have plans to create a true multitasking OS (well, I have plan like this ...), it would be important to have own stack/zero page per processes.
Time for a reality check: when it comes to running several concurrent running processes necessary to run a system, we're dealing with an 8-Bit CPU with 64K address space and just interrupts, no memory management, no memory protection. You design the programs to run on this machine+OS - not the other way round.

There are quite some good examples, which run complex processes on a 65xx (Lee's web server on the VIC-20 comes to my mind here), but you should keep in mind that the 65xx and its kin were designed to control small machines, and not sport a multitasking GUI with 16-bit stereo output, 24-bit graphics, video codec, etc. :wink:

It's understandable given today's computers, we're spoilt - and when we actually go back to those old machines we sometimes ask outselves if a good deal of the features now seen in the new machines couldn't be re-implemented in the old machines?

Indeed that *is* one of the main motivations for me. If you see some of the games, tools, demos done in the last years for C64 and VIC-20, we couldn't imagine they would have been possible at the time we originally owned the machines first, in the 80'ies and maybe still early 90'ies. In the meantime, the development methods (cross-development, including emulators) have advanced to a state, that lots of ideas only thought possible for 16-Bit+ systems also became feasible on our beloved VIC-20s and C64s. And that still did not necessarily require hardware enhancements!
[...]The colour SRAM can be smaller of course. 1K, or a bit more :) to allow to "switch" between for some kind of tricks I don't know about really, maybe it's useful for something, I have no idea, I also lame with C64 advanced techniques like FLI, etc ...
O.K. let's take the cat out of the bag: Please take a good, *thorough* read of this thread:

Introducing VFLI for VIC-20: 208x256 pixels in 16 colours!

Feature list:

* Overscan 208x256 bitmap,
* 8x1 pixel attribute cells (instead of 8x8 or 8x16),
* 3 global colours (background, border, auxiliary) redefined on each raster.

There you have the 3K "hole" in $0400..$0FFF filled, so VIC-I can access it. Colour RAM is expanded from 1Kx4 to 16Kx4 so VIC-I can read new attribute data each new raster. The mode works with a display routine, which runs cycle-exact in the interrupt. A converter on PC can take any image and convert it to VFLI.

And here's a bigger project, which tokra and I did mainly in the years 2010..2013 to explore what is already possible on the VIC-20 with hires graphics, when no modifications on the mainboard are done.
Yes, of course, a SID is wanted too, just in case :D
Here are another two nice threads I'd like to point you to:

o Sid-20 mod for the Vic
o Sid Vicious - VIC 20 SID emulation

...

I just wanted to point out these things to show you, what has been done in the last years so you have an idea what I and others here in Denial are up to regarding software and hardware on the VIC-20. This is not meant in any way to discourage you. But before you jump into a project, that might produce as hardware only 'one of a kind', why not take the time, see what others have already done, take it as incentive - and release something (maybe in a team?), that a lot of fellows can use their original VIC-20 to run on?

So, because I didn't explicitly write it in my first response:

Welcome to Denial! :mrgreen:

Michael
User avatar
lgb
Vic 20 Drifter
Posts: 25
Joined: Tue Apr 26, 2016 8:10 am
Website: http://lgb.hu/
Location: Hungary
Occupation: System engineer

Re: VIC-I addressing (newbie) question

Post by lgb »

Mike, thanks for the information and links. Surely, I could think I am not the first (it would be a naive thought!) who thought about these. Just because I am new here (and also for the VIC20) I am not so familiar with the topics already mentioned/discussed etc. I've already read some topics on the forum just browsing around, but surely it's harder to read everything for a "baby" like me, I meant: you know, even old jokes are new for a new born baby :) This post meant to be an excuse that I am off-topic sometimes or whatever :) Thanks for your patience and the links too!

The other factor is my personality, that even with "retro computing" (an odd notion, but still) I am interested to "mix" with new ideas from current day's computing with the old hardware/software solution. Ie, the idea of multitasking OS, more modern storage solutions (like SD card, but not as with sd2iec but *also* a more direct and faster connection), and so on. Some people I've "met" in the "retro scene" find that odd, that I should stick with the old things if I am interested in that. Well, that's me :)
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: VIC-I addressing (newbie) question

Post by Mike »

lgb wrote:[...]more modern storage solutions (like SD card, but not as with sd2iec but *also* a more direct and faster connection)[...]
... if you think about a RAM-link like method (i.e. pumping data to/from SD card with some kind of DMA, circumventing the slow serial bus), you're running into open doors with me. That had come up in yet another hardware project here, but never actually been followed through. :?
User avatar
lgb
Vic 20 Drifter
Posts: 25
Joined: Tue Apr 26, 2016 8:10 am
Website: http://lgb.hu/
Location: Hungary
Occupation: System engineer

Re: VIC-I addressing (newbie) question

Post by lgb »

Mike wrote:
lgb wrote:[...]more modern storage solutions (like SD card, but not as with sd2iec but *also* a more direct and faster connection)[...]
... if you think about a RAM-link like method (i.e. pumping data to/from SD card with some kind of DMA, circumventing the slow serial bus), you're running into open doors with me. That had come up in yet another hardware project here, but never actually been followed through. :?
Wow, I wouldn't think so far :) For me, that's already enough to be able to access the SPI bus directly but instead of bit-banging through 8 bit shift register given by the hardware (if I remember correctly it turned out on forum of 6502.org that VIA can't be used for this easily ...). Eg for Enterprise-128 (my favourite Z80 based computer) has "SD card cartridge" built, using this scheme with a CPLD, it allows the fastest read/writes what a CPU can do even with "over clocking" the Z80 :) Using DMA etc would help to push the limits even further, that's true. But even with that I was able to write a "demo" for Enterprise-128 which streams music from the SD card in quite good quality (ie 32KHz, 6 bit D/A of Ep-128, but if a PC "covox" like solution is used on the printer port, it can be even 8 bit, or well, maybe 16 bit, near 44KHz, but Z80 is too slow at this point on the default 4MHz). And yes, I've already read topics on this, in the forum, I try to catch the topics meanwhile :)

With even having DMA, it's something like the Evolution Commodore plus/4 (wild-) demo, if you know that. I'm bit ambivalent here already (even me ...) that basically the Commodore is used as a "display" only :) :) There an external hardware presents the frames what the TED "sees" and display, so the CPU itself does not to too much.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: VIC-I addressing (newbie) question

Post by eslapion »

lgb wrote:... VIAs - in theory - can be also replaced to modern parts, and the "new CPU" is free to access them in "fast mode" too ... anyway they are fed with the original clock in VIC20 mode, so it wouldn't introduce an incompatibility because of the different timer meanings etc then). I am not sure though, that the original "famous" bug of VIAs are fixed in the CMOS version which made the hardware shifting impossible on the serial IEC bus, by the way...
It is fixed in the Western Design Center's W65C22N VIAs which sell for a very small price on http://www.mouser.com

Unlike most CMOS VIAs, the W65C22N is a direct drop-in replacement because it supports IRQ line sharing.
Be normal.
User avatar
lgb
Vic 20 Drifter
Posts: 25
Joined: Tue Apr 26, 2016 8:10 am
Website: http://lgb.hu/
Location: Hungary
Occupation: System engineer

Re: VIC-I addressing (newbie) question

Post by lgb »

eslapion wrote:
lgb wrote:... VIAs - in theory - can be also replaced to modern parts, and the "new CPU" is free to access them in "fast mode" too ... anyway they are fed with the original clock in VIC20 mode, so it wouldn't introduce an incompatibility because of the different timer meanings etc then). I am not sure though, that the original "famous" bug of VIAs are fixed in the CMOS version which made the hardware shifting impossible on the serial IEC bus, by the way...
It is fixed in the Western Design Center's W65C22N VIAs which sell for a very small price on http://www.mouser.com

Unlike most CMOS VIAs, the W65C22N is a direct drop-in replacement because it supports IRQ line sharing.
Thanks for the information about the bug fix :) I've already got 65C22 (not the N though) from mouser, also with a 65C816. I think, indeed, that 65C22 and 65C22N is the very same, except for the fact about the open drain IRQ pin (so it's compatible with the NMOS design, though I am not sure - as usual - about the logic level differences to mix NMOS and CMOS parts, also the reason of 74HC and 74HCT parts for example ...)
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: VIC-I addressing (newbie) question

Post by Mike »

lgb wrote:With even having DMA, it's something like the Evolution Commodore plus/4 (wild-) demo, if you know that. I'm bit ambivalent here already (even me ...) that basically the Commodore is used as a "display" only :) :) There an external hardware presents the frames what the TED "sees" and display, so the CPU itself does not to too much.
Well, more "kind of DMA" (as I wrote), because the cartridge hardware (once again) wouldn't have any direct means to access the internal RAM.

Instead, a controller on the cartridge is supposed to handle the DOS functionality (not only for the SD card file system, but preferably also within *.d64 disk images) - on DOS level! - but instead of going over the serial bus, the controller prepares special routines in the I/O2 and I/O3 area with unrolled PIO loops that look like this for LOAD:

Code: Select all

LDA #data
STA $1001
LDA #data
STA $1002
[...]
... and like this for SAVE:

Code: Select all

LDA $1001
STA PIO_register
LDA $1002
STA PIO_register
[...]
When these routines have transferred a certain number of bytes, a RTS at their end returns to house-keeping code, which instructs the controller to prepare the next set of transfers, and which would be a rather small stub added to the KERNAL I/O routines (compared to the DOS in the controller), wedged into the KERNAL vectors. For LOAD, we'd get ~6 cycles/byte, i.e. a transfer rate in excess of 150 KB/s - similar figures for SAVE. :)
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: VIC-I addressing (newbie) question

Post by eslapion »

lgb wrote:... though I am not sure - as usual - about the logic level differences to mix NMOS and CMOS parts, also the reason of 74HC and 74HCT parts for example ...
CMOS VIAs are "logic level" compatible with NMOS ICs and TTL logic ICs with a logic threshold at about 1.5V.

The difference between HC vs HCT logic circuits is related to the voltage for logic threshold.

On HC/AHC ICs, the logic threshold is defined as 50% of Vcc and these circuits can operate from 2V to 6V therefore if powered with Vcc=5V, the logic threshold is about 2.5V.

On HCT/AHCT ICs, the logic threshold is defined as 30% of Vcc and these circuits can operate from 4.5 to 5.5V therefore if powered with Vcc=5V, the logic threshold is about 1.5V - these properties makes them compatible with voltages which are extremely close to those used with TTL logic circuits such as popular 74LS series chips.
Be normal.
User avatar
lgb
Vic 20 Drifter
Posts: 25
Joined: Tue Apr 26, 2016 8:10 am
Website: http://lgb.hu/
Location: Hungary
Occupation: System engineer

Re: VIC-I addressing (newbie) question

Post by lgb »

Well, since I am too much in my own solutions, multitask OS, etc, I was not so about the compatibility with anything, but indeed you're right, it would be a better thing in general. Moreover, I also thought that SD2IEC with some kind of parallel connection "hack" can be useful, and it even can give you some kind of light DOS functionality, which is already have anyway, just for - in general - via the serial IEC bus. Another idea with SD2IEC: as it doesn't use too much the TX/RX serial port pins (maybe for debugging) a super cheap Chinese wifi module can be connected (usually use serial port, with AT-like commands), so a cheap wi-fi solution is there too, much cheaper than TFE/RR-NET etc for C64 and at least it's wi-fi :-P Which can be accessed via IEC serial, or in case of the parallel hack, through that too. Of course standard d64 disk images via the Net can be also possible, I guess, this way (however since AVR MCU does not have enough RAM, it can be "slow" when "not cached" parts tried to be reached ... hmm).

But for maximal throughput (and back to the SD card!), SD cards have the multiple block read commands, which is nice, since a simple command issued, and the SD card will "stream" about the full card for your from block to block. It's ideal for some kind of audio/video playback solution, if bandwidth is enough (not the SD card's one, it's probably OK with modern fast cards, but the "other end" :) ). I did exactly that with my audio player on the Enterprise-128:

https://www.youtube.com/watch?v=VRZtURARmTw
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: VIC-I addressing (newbie) question

Post by Mike »

The controller would of course use the fastest possible method to access the SD card contents. The real bottleneck is at the interface of the cartridge to VIC-20.

The wedge itself could be activated with auto-start code in BLK5, doing some initialisation, then pointing the KERNAL vectors to the wedge code which is preferably also located in the I/O2 or I/O3 area, and finally replacing BLK1..3 and BLK5 (possibly also RAM1..3) with the user's preselected memory configuration before BASIC is entered. The wedge should be restartable with a simple SYS command in case it was deactivated.

P.S. A variant of these transfer routines could also be used to pump digi samples into the volume register of VIC-I, so something around 32 KB/s sample rate and 4-bit-digis (extra bits with noise-shaping, etc.) would also be possible on VIC-20.

With "stock" hardware, this has been done by Boray some time ago. :)
User avatar
lgb
Vic 20 Drifter
Posts: 25
Joined: Tue Apr 26, 2016 8:10 am
Website: http://lgb.hu/
Location: Hungary
Occupation: System engineer

Re: VIC-I addressing (newbie) question

Post by lgb »

Well, back to the original topic, VIC-I addressing :) While writing my emulator I met with problems I don't know how VIC-I solves. Especially with modifying screen/chargen/colour addresses. What happens if you modify these (or just one of them, etc) at a given place? As far as I can imagine, VIC-I somehow needs to store the original "pointers" set by the user. But also, it needs "run" an active pointer, ie to the current displayed character position. Also, within a raster line, screen/colour RAM pointers needs to be incremented one by one, but then, for the next raster, they should be "reset" to the one to the original for the start of that text line (unless, if it was the last scanline of character, 8/16 depending on the character height setting). Now what I can't clearly see: what happens if I write a new address to the VIC-I registers, how it affects (and when ...) the visible result ...

My emulator currently does a raster line in once (which is not correct anyway) but it's quite OK for the BASIC at least :) However I tried to load game "pulse" directly injected into the memory, and what I got is a flickering, jumping screen with other interesting effect. Maybe I should logging what pulse exactly does, I guess the problem that it does some kind of tricks (?) with modifying VIC-I registers rapidly I cannot emulate well, while BASIC/KERNAL just sets registers once, so it's OK otherwise ... Oh, one thing I don't emulate at the moment: multicolour characters ...

http://lgb.hu/temp/vic20/index.html

Two screenshots can be seen here. The odd one with pulse is like that, with altering between several bad (like this) and good pictures, with some white lines appearing meanwhile. Ok, I know it's hard to tell from a picture, where I am wrong :) but I have the hope, that it's about the problem, I've described at the beginning of this post (currently I set user defined memory addresses _once_ during a frame only ... which is - I guess - really not what VIC-I does ...).

Thanks in advance!
Post Reply