Denial

groepaz wrote: ↑Mon Aug 29, 2022 10:37 am I mean cpu clock (NTSC) vs cpu clock (PAL)

Ah, ok. Both could be arbitrarily generated by a custom 6560/6561, regardless if the VIC-20 board is PAL or NTSC.

That will not work - The videotiming is tied to the timing of the machine. (Unless you want to implement a framebuffer in the FPGA and output video async) Good point. I was thinking getting at least some color on my PAL composite monitor with NTSC timing. It supports the timing but not the NTSC chr...

Conceptually I can generate most "reasonable" Frankensteinian video formats with corresponding CPU clocks, or, indeed, other CPU clocks. Sure, but I was not thinking of any franken-timings. Only selectable standard NTSC or standard PAL regardless of the machine the chip is in. Possibly wi...

Am I missing any other crucial system differences? You would still need to switch the KERNAL to accommodate different init values for the VIC registers and different VIA jiffy clock and RS232 timer values. Also, something like PAL60 would create a new platform with no pre-existing software and hard...

A little thought here: As a 6560/6561 replacement you own the generation of the system clock. Wouldn't it be possible to have the system switchable between PAL and NTSC video timing regardless of the system it is in? Granted it will still modulate the chroma as PAL on a PAL Vic20, but many monitors ...

This question keeps coming up and people say lots of things, but I don't understand why looking at $e475 fails to do the trick. It seems like the simplest thing on earth. bit $e475 bmi is_pal etc. Am I just nuts? Is that really accessible from within the VIC? Besides it’s far nicer to rely on direc...

I wrote some test programs when tweaking the vice implementation, here: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC20/split-tests/ Try timing. It tries to sample those registers for every cycle and allow you to save the result as a file. Note though that I have very limited exper...

It's what you call 'the Terminal Software version" It has the different ship. And the black terrain. But my cassette pre-dates that - and it was published by Rabbit. Very cool, have never seen that! Could you make a .tap of it? Would be very interesting to see how it differs from the other two...

this one: skramble_rabbit_software.tap ?

Commonly enhanced kernals would strip out RS-232 routines and/or tape routines to allow space for added code.

If it works on a 1541 in 1540 mode, then it isn't the normal timing issue, rather some other discrepancy. Probably have to check the diffs between the roms to find out.

Looks pretty weird. It could be a race condition with the 1540 timing, but you'd think that would have been noticed. Still it wasn't produced that long so I suppose something could have slipped through the net and then have been fixed in the 1541. What happens if you switch a 1541 to 1540 timing wit...

Sounds weird... could you post some example code?

I wrote that code. It refers to a bug in the preliminary CPLD for v3.2 which I found when reverse engineering the CUPL code to implement emulation of the cartridge. This bug is AFAIK not present in any released v3.2 CPLD versions. Thanks for the confirmation, I noticed this is commented out so ther...

I'm playing around with code to use the various modes of the FE3 and noticed the following in the VICE code base /* emulate Final Expansion v3.2 Super ROM write bug */ /*#define FE3_2_SUPER_ROM_BUG*/ I think it refers some discrepancy in whether writes go to bank 0 or 1 in Super ROM mode but I can'...