Re: VIC20 core talk

Ok, that is the issue.  DVI-D monitors do not work with the _SD versions.   I am only using DVI-D.  I had to drag out an old-school VGA monitor to test a few things.

52

Re: VIC20 core talk

VGA also probably won't work with SD if it isn't one of the special multisync ones supporting 15kHz H frequency...
Better is to use a TV supporting the PAL video standard - or an original 1702 via its front composite in (and real scanlines) wink

In the meantime I am on debugging the core boot lockups. They are really rare, so it takes quite some time to get my core into this state. When it happens, I saw the kernel gets stuck at the end of its reset routine at address $FDEB (where it continuously initialises the VIC-I in an endless loop).

Now I know where it stops, but still no clue why this happens. Continue debugging....

/WoS

Re: VIC20 core talk

It's odd for sure.  But like I said, I never saw an issue when using the 15Aug13_r0 replay firmware.  I have only seen this problem since updating to the latest version.  I don't know if that is coincidence or not.

Re: VIC20 core talk

I'm currently using VGA because of a sync bug with my DVI-D monitor, but as soon that is sorted out I am going for DVI-D. Please don't remove support for that permanently. smile

55

Re: VIC20 core talk

JimDrew wrote:

It's odd for sure.  But like I said, I never saw an issue when using the 15Aug13_r0 replay firmware.  I have only seen this problem since updating to the latest version.  I don't know if that is coincidence or not.

Not sure anymore. I think the ARM does its part correctly, it's the core directly which gets stuck at the mentioned point. Of course still possible that changing some upload/reset timing caused this. Currently not feeling well, I probably caught the flu, but I hope I can continue this weekend.

/WoS

Re: VIC20 core talk

Get some rest!  You are no good to us if you are sick for a long period of time!  wink

57

Re: VIC20 core talk

Thanks, Jim! I'm in bed - with my notebook. wink  So have to do all with simulation only...

Could not find the issue with the boot process yet. It is definitely that the core hangs after reset, it happens (sometimes) with a pure core reset (when pressing F11  - so no ARM involvement except pulsing the core reset signal once). After a few trials, the core freezes and after another reset and it works again - so all ROMs etc. are set up fine, it has to be on the FPGA.

Currently I check the old (existing) code, several parts do not reset properly with the reset line from the ARM (but only at first FPGA config). So I assume some bits do not come up properly. For now I added some reset to the VIC block itself.

I also did finish the keyboard mapper and tested on the VIC-20, but this I'll post in the Replay lib section, as I moved the code there.

/WoS

58 (edited by WoS 2014-02-22 21:07:13)

Re: VIC20 core talk

Johey wrote:

I'm running the latest (as of yesterday evening) VIC20 core, but I still need to find out how to build and update the ARM fw. Mine is almost half a week old now. yikes

I notised two glitches. First, not all keys on the keyboard work. 1 and 3 works, but not 2. Second, it does not start up all the times. It freezes at the checkboard screen. Though I woulnd't raise formal bug reports until I've successfully updated to latest and greatest versions of all bits and pieces.

For the keyboard issue there is a solution now, the VIC-core uses this module which allows modifications of key mappings:
http://www.fpgaarcade.com/punbb/viewtop … 1427#p1427

For the second the only way is to reset the core for now by pressing "F11" (exists in the latest ARM FW) or by the "reset core" item on OSD. I am on it to track the problem. It only happens on start up, once the core is running it is stable (had stress tests over >2d already).

You don't need to build the FW yourself, the SVN contains the binaries directly to use on your sdcard (copy whole directory and then select the INI there). check them in once I tested them (this may avoid issues with different yartago releases):
.../sw/arm_sw/Replay_Apps/rAppFlashUpdater/sdcard

/WoS

59

Re: VIC20 core talk

My PRG loader still makes troubles. So I won't try to fix yet as it needs a full redesign with the new (DRAM enabled) VIC-20 core. So I wait for the new floppy framework first and then fix all together to the generic setup.

In the meantime PRG files can be set up in the INI by loading them two byte below the required start address. So the main code will be located at the right adress. In case of a $A000 module it is no big issue, set the start address at $9FFE and the two header bytes are written to a non-existent memory (if switched off in the config).

Not really pretty, at least by that I was able to set up the VIC+SuperEpander+3k  INI file again and this setup works stable. One can use this workaround to set up an own module configuration. Checked in this INI file to SVN.

In the meantime I might have an explanation why some VGA displays (and DVI-A displays) can't sync properly. I figured out the picture content starts extremely late (when looking on a H line to H sync timing). On top, the VIC of course use the (usually non-supported) 50Hz V rate. But this is given by the video generator from the framework, the VIC-core just syncs on this timing.

I may try another video mode and check if it will improve the situation or implement a mode to invert the sync signals in the video converter (and have OSD settings for the polarity).

I also had another idea: I own a 1520 plotter (and still have paper and pens for it). I thought of a 1520 emulation plotting on a second overlay on the screen which can be switched on/off via a special key wink   Just need to get my hands on its firmware...

/WoS

60 (edited by JimDrew 2014-02-26 02:04:18)

Re: VIC20 core talk

The latest version of the VIC-20 core crashes the FPGA Arcade when any of the _SD versions are selected.  I have to physically power off the unit to recover.   All other versions appear to work fine.   Also, this is first time I was able to see Phoenix on a normal (non-DVI-D) monitor - works great.  However, the VIC-20 core apparently requires DVI-D, or least it doesn't work with my VGA LCD monitor (screen mode not supported message).  The .d64 support seems to work fine.  I made a .d64 of my original 1540 Test/Demo disk and ran the BAM test and it splits the display between two screens for the VIC-20 (like it should).  I had some flash backs to High School.  smile

Re: VIC20 core talk

Oh, I missed things have happened here. I cannot reproduce the sync issue anymore, and the keyboard is now working properly. This is awesome, wolfgang!

Re: VIC20 core talk

i bet i can reproduce it if i just had a board to do it on wink
the sync issues was nasty on my screens.

Re: VIC20 core talk

It used to be for me too. smile

Re: VIC20 core talk

That sounds really promising then, good news!

65 (edited by WoS 2014-03-04 23:07:56)

Re: VIC20 core talk

Johey wrote:

Oh, I missed things have happened here. I cannot reproduce the sync issue anymore, and the keyboard is now working properly. This is awesome, wolfgang!

Ah, sorry. And thanks wink

Forgot to mention than I checked in some updates this weekend. Just mentioned in the ARM section that I improved the FW so it is also possible to load PRG files properly to the VIC-20 memory again (files with the target address in the first two bytes are handled by the ARM now - I took the chance together with changes for Arnims proposal on the ROM loader reset, it is all part of the latest firmware).

I also improved the video scaling again, so the picture should be quite ok now. About the sync loss - still no idea, I just did add more resets of some counters/registers in Mikes sources here and there (even if I am sure they should not be needed, but the symptoms show it could be some init issues). And if the monitor tells you "not supported" it is very likely because of the 50Hz PAL version (I have no 60Hz NTSC version here I could use as reference for implementation).

I updated and tested also the INI files and they should work well (also the _SD ones). If one of the ini setups do not work, please be specific about the name of the file and its version. I compare each with SVN diff and also load each of the 8 versions shortly on the board, but nobody is perfect  big_smile - and I've made several changes lately.

Please be aware that I removed some of the INI variants, basically only three versions are really required to cover all relevant memory configurations of the VIC-20:
- unexpanded (0k)
- 3k expansion (3k)
- all memories (35k) - can be used for programs requiring 8k and 16k and $6000/$A000 cartridges

Furthermore there is the SuperExpander INI file (including the 3k expansion).

So take care when copying updates on the sdcard to remove obsolete, old ini files...

/WoS

66

Re: VIC20 core talk

I was lucky and found a US VIC-20 on Ebay. I really hope it is still functional (at least the VIC, everything else I can fix easily), then I have a reference to set up the NTSC mode as well   big_smile

It seems these computers were quite common in the states, I found a lot of offers. Looking at the C64, it is exactly the opposite: tons of offers in Europe, nearly none in the US. But I am sure I'll find a NTSC C64 or C128, sooner or later...  wink

/WoS

Re: VIC20 core talk

Keep it up Wolfie!

Re: VIC20 core talk

I just got a replacement board from Mike that actually works \o/ I have just put it into it's casing and tested all the stuff that i missed out during my weeks without a replay.
The Vic20 core works a lot better now. I got an occasional black screen that i could get out of by pressing F11.
No sync issues in the menu or in any demos so far! Good work!

69 (edited by WoS 2014-04-01 17:49:07)

Re: VIC20 core talk

Great, thanks for this feedback!
Ok, still some initialisation issues, really strange where this comes from.
But I am sure giving some time and we will iron it out, as long as a second reset with F11 works wink

Edit: just found VIC-DOOM on the web, I had to put it on SVN (within vic20/sdcard/demo) and added a "reference.txt" containing the link where I found it (for people interested in the source code). The D64 file works nicely on the actual version with 35kB expansion! Take care, 18yrs+  cool

Post's attachments

VIC-DOOM.png
VIC-DOOM.png 146.83 kb, 3 downloads since 2014-04-01 

You don't have the permssions to download the attachments of this post.
/WoS

70

Re: VIC20 core talk

Updates on the new (separated) 1541 core: write to disk media is supported now. Nevertheless, the ARM firmware lacks yet writing back the content to a real sdcard file, so changes are only made in memory. This means: after changing the d64 file via OSD or reset the core all modified content is lost again.

But its a good start, as it means the 1541 stream write HW works well, reformats gcr code back to d64 code and properly passes the data back to the memory (all done on the fly on the FPGA). It works with the regular and the jiffy DOS setup (so I suppose it should also work with other ROMs our there).

I updated the vic20 to use this new 1541 setup, so one can set a d64 file and have some fun with 1541 commands...  wink
c64 update is following soon, will be posted there.

/WoS

Re: VIC20 core talk

Well, if you have GCR support then it's not much of a stretch to add .g64 file support since that is just GCR data.

72

Re: VIC20 core talk

Of course I handle GCR, otherwise I won't be able to simulate the real HW setup of a 1541! This _is_ real HW I am setting up. Passing and storing the stream data in a generic framework (= avoiding to flash the ARM for each new format or fix in the format) is a totally different topic.

There is a fundamental difference in the d64 (or ADF) and g64 format - especially how to handle such formats in pure HW  - g64 and many others have no clean block setup, they were not invented with any HW design or generic setup in mind. This is not a PC running an emulator, and I am not following an approach to add soft cores for this purpose as others do and add an additional (fourth) development environment for this to handle it...

/WoS

Re: VIC20 core talk

OK, good.  So, if you are clocking the bitcells in through the data separator then you could use .scp image files, because that's what those files have for data.

74 (edited by WoS 2014-05-27 19:48:34)

Re: VIC20 core talk

No, what I said for g64 is valid for scp as well.

Requires specific format handling on the ARM prior to use on FPGA and no simple block reader. On top, it requires also more work on FPGA side to use it, the data from g64 files just need to be shifted/passed to the 6522 port with the correct timing. And I expect issues as the scp files seem to require a higher bandwidth from sdcard over ARM to the FPGA as well (all serial).

Edit: --> will take more time and some more good ideas to add support for all this...

/WoS

Re: VIC20 core talk

Yeah, I have discussed all of this with Mike.