Re: C64 core talk

if you actually want to check out those REU demos, sd2iec (or any other mass storage) wont help you - as they are all supplied as REU image files and none of these even come with a loader program to load these into the REU memory (the only existing implementations of 16MB REUs, ie the 1541u and the Chameleon, let you load these images via their menu system)

as for parallel speeders... i wouldnt bother with them. jiffydos is reasonably fast enough for anything that uses kernal routines. speeddos style parallel cable should be very easy to implement however (and most programs that use parallel cables work with it.... not that using burstnibbler or sth like that makes a lot of sense in an emulation context :=))


Re: C64 core talk

Great, that' even easier to set up, as it is the actual way to get all the ROMs etc. into the memory on Replay (if the ROM are mapped to the dram on the Replay, of course).

The 1541 on Replay (included in c64 and vic-20) currently also uses an whole d64 image moved directly from sdcard to dram via the OSD menu (and the 1541 hardware contains an floppy emulation reading disk tracks from this memory). With the fileio support from Mike, a core could even load it from sdcard directly to memory, if needed (like the amiga ADF support works).

Loading the RAM content from sdcard to memory should also work for georam already, just have not tested yet. Saving from memory to sdcard is possible as well, this part is just yet missing to be used for the OSD menu. Just need to check if they just use ordinary dumps or special file formats.



Re: C64 core talk

I had speeddos back in the days. And dolphindos. Actually I cut and paste the best of the two into my own, but unfortunately the binary is gone sad

79 (edited by WoS 2014-10-29 21:29:27)

Re: C64 core talk

Ah, I have got some ROMs and schematics from dolphin 2.0 and even 3.0, that's a starting point...  Funny thing is I implemented some HW to generate GCR from nibbles fourth and back to handle d64 to/from the floppy head logic at full speed, the dolphin HW does just the same "on the other side of the CIA", so to say  big_smile

Edit: Just had a look, although speeddos uses a parallel cable, it was not so fast: its mentioned to be in the range of jiffydos (which I bought and use for the Replay core, I am really happy with it).


80 (edited by JimDrew 2014-10-29 21:48:54)

Re: C64 core talk

The need to have a real hardware interface is very real... to the point where there are a couple of C64 re-work projects that put the C64 components on a new motherboard that is ATX size, with real hardware interfaces.

The biggest hurdle with retro-computing will always be how to transfer data from real media to some other format, even as simple as a SD media card.   It's the main reason why I created SuperCard Pro.  I can make an image file of a real disk (flux level) and that image is supported by a variety of emulators already, including Replay (Mike has it in the Amiga core).  If I wanted to plug a Lt. Kernal hard drive into a real C64 I can do that, and that gives me a large hard drive that is accessible just like it was a large floppy drive (which is how they all worked).

As far as parallel fast loaders.  I have them all here.  I think I have just about one of every type of 1541 hardware add-on and disk copier ever made - that's what I did, so I had to know what the competition was doing.  DolphinDOS was very popular in Europe, ProDOS was another one.  None of them were popular here in the U.S.  JiffyDOS was the most common of all of the fast loaders, and you can still buy the ROMs (and the "overlays", which is the ROM image) from a couple of places that licensed it from CMD.

How much work would it be to add 8K of static RAM support and additional EPROM support to the 1541 core?  If you could map 8K of RAM to $6000 or $8000 (selectable) then that would handle all of the disk copy programs out there that used extra RAM.  If you added support for 2K of ROM at $1000, then I could really test out your 1541 core because Supercard+ for the 1541/1571 had 2K of ROM at $1000 and 8K of RAM at $6000.  I was able to duplicate everything ever made for the C64 using that hardware.  My GCR editor would allow me to test various quirks in the data separator hardware that were used for copy protection.  Did you ever add support for G64 image files?  There are tens of thousands of those out there that are used with WinVICE and such so that copy protected games can be played... G64 support is the number one reason why people want to use the 1541 Ultimate 2 cartridge - number 2 is the 16MB of REU.

If you added parallel support and support for extra RAM/ROM, that would be great - I support the parallel cable too for speeding up disk copying.  I could read or write an entire disk in ~7 seconds.

Of course, we need a way to disable all of these extra goodies because copy protection routines started checking for my Supercard+ board, cartridges, and even parallel cables!


Re: C64 core talk

JimDrew wrote:

How much work would it be to add 8K of static RAM support and additional EPROM support to the 1541 core?  If you could map 8K of RAM to $6000 or $8000 (selectable) then that would handle all of the disk copy programs out there that used extra RAM.  If you added support for 2K of ROM at $1000, then I could really test out your 1541 core because Supercard+ for the 1541/1571 had 2K of ROM at $1000 and 8K of RAM at $6000.

Piece of cake (hopefully wink )...  I did implement 8k RAM at $6000, 8k RAM at $8000 and 8k ROM at $1000 (only 2k can be seen as the VIAs starts at $1800). So no need to select the RAM position, both fit easily on the FPGA (at least when no CS instance is used, which also requires some RAM blocks).

The new ROM can filled via the INI file as usual, the start address of 1541 ROMs is 0x0004xxxx, for $1000 it is:

# 2k ROM at $1000 in 1541
ROM = <filename.bin>, 0x00800,0x00041000

I checked in a test version on the SVN, the c64 core still starts and works as usual (and loads disk files). I looked twice but still no guarantee that the RAM decoding is fully correct already (I had to modify the shadow areas of the original RAMs as it used a minimum decoding for it).  I have no quick way to test it (except a full simulation setup and design a simple 1541 kernel for testing this areas - I think I had some 1541 memory monitor somewhere, need to find it.)

Btw: The other VIC-20 core still uses the unexpanded 1541 (this uses a different 1541 setup).


Re: C64 core talk

Cool!  I will test this out.  Again, we need a way to disable these neat add-ons, and have the exact address decoding, complete with all mirrors, etc.  Most all copy protections (V-Max!, Vorpal, etc.) all check the 1541/1571 memory map and won't load when there is extra RAM, etc.

83 (edited by JimDrew 2014-10-30 16:53:31)

Re: C64 core talk

I tested the core.  I added the supercard.rom file to appear at $1000 and ran a board test, which passes.  I then looked at the drive memory with my Disk Mon program and discovered that memory map is missing a bunch of stuff that is required for just about everything made after 1987 to work.  It was very common that games periodically checked the drive memory map, looking for extra RAM, mirrors of the VIAs (some actually used the mirror address and not the actual address), unmapped regions, or in the case of V-Max!, Vorpal, and a few other common protection schemes, the presence of the Supercard+ board's ROM at $1000.  Supercard+ had the ability to have a switch added so you could kill the memory mapping of the RAM/ROM to return the drive to normal.  If you need to know the exact layout of the drive memory map, let me know and I can give that to you.  I don't know if you still have a real 1541 disk drive to look at.  On disk 2 of the Supercard+ v6 disk set, you will find my Drive Mon program.  It's a disassembler/memory viewer for the drive RAM.

I then tried my GCR editor, which appears to work pretty well - except, there is a problem with the data separator timing.  When you convert the d64 to GCR, the timing is off a bit.  There are way too many sync bits in a row (there is suppose to be 40 total), and the gap between the end of the sector and the first sync (before the header) is missing.  So, I see the exact number of bytes (320) after the data block ID and then the next sync - no gap.  The syncs are strings of 6-7 bytes of FF's, when it should always be 5 FF's (standard CBM format).

When I used any of my copiers or analyzers the density calculation based on the data separator is way off.  Tracks 1-17 should be density level of 1, and my analyzer shows them as 3 (which would be for tracks 25-30).

My Supercard+ intro screen doesn't work properly under the C64 emulation.  I have a vertical blank scroller routine and that pauses and blanks for quite some time while running.  It should just smooth scroll colors in the background across the entire screen, including the borders.  I don't know if I have the source code to the scroll routine anymore (but its tiny).  That intro screen was written in BASIC and compiled with DTL.  The scroller code is loaded as a separate file into the cassette buffer (I think) and executed.  I do have the BASIC programs still, so I can check.  Here is a link to the Supercard+ disks (v6 was the latest released), and a link to my supercard.rom file:



It's neat to see it work.  I hope you can make all of my programs work under Replay.  WinVICE can run some of my stuff, but not all of it because I really pushed the limits of what the disk drive can do.  I take it that writing is not implemented yet?

I do have REU support in most of my copiers, so if you load the GCR Nibbler it should auto recognize a REU and its size (128K, 256K, or 512K) and report that as -1764, -1700, or -1750.  I have lots of test code and info on the REU.


Re: C64 core talk

Thanks for this feedback and the test code Jim, this really helps!

The scrolling and raster stuff should work - I am concerned I destroyed something with my later changes fixing the interrupt handling, I had another demo which already worked and didn't do anymore now...

It looks like I have a bug in the LUT checking the density in relation to the track to generate the GCR code. Intresting that it still works somehow with the original 1541 firmware. Will be fixed.

And yes, the options for the additional 1541 RAM/ROM settings should be switchable, I just did it as quick hack to see if it fits this way still into the FPGA. This way I killed the original decoding with the mirroring etc. E.g. after the VIA the 8k ROM I hacked in should appear again, but it was quick to set up and I couldn't quickly find a smaller ROM  big_smile 

When looking at the other issues I also do a proper update on configuring the 1541 settings. So got some tasks for the weekend wink

For now I set up d64 to have something available to work with and to load some stuff in an easy way - as I mentioned some time ago. With Mikes generic fileio implementing g64 should be no problem anymore. I would like to have at least d64 and g64 for the floppy part plus crt and tap, maybe t64 for the c64 part available via OSD. I'd also like to improve proper prg loading for basic progams (for now it does not set some zero page vectors were the basic program ends, so any variable initialization destroys the basic code).

ROMs are still emulated by FPGA block RAM in the 1541 part, I'd like to have all RAMs and ROMs in the external DRAM (similar to the C64 core). The advantage would be that I can use the Replay file loader only and can remove my own modified loader which makes everything simpler. And it will be possible to generate snapshots from any RAM to the sdcard on the Replay (might be useful for debugging).



Re: C64 core talk

gpz wrote:

Just need to check if they just use ordinary dumps or special file formats.

just plain linear memory dumps for georam and reu (although georam dumps are very uncommon, i only know of one release that comes with a georam image)

Thanks for this info. Good to hear, will have a play with it (at least only georam for now) to have load/save capabilities via OSD for this memories.



Re: C64 core talk

If you ask any U2 owner, you will find it is not for the .d64 support.  There are tons of devices that give you that capability, but NOTHING else (until I release the u1541) gives you G64 support - and that is something that people use all of the time with copy protected disk images and for running custom demos.

most people use cracked games or watch demos, and none of that requires G64. There arent "tons of devices" for proper D64 support, there is the 1541U and the chameleon (which supports G64 just fine as well, and even passes more drive tests than any other existing emulation, btw) - anything else will not work with custom loaders and drive code, which really is the main reason for full drive emulation. copy protected disks are something a minority uses, believe it or not.

There are many programs where they change the density level for a string of bytes (typically a full sector), and those do not work under WinVICE, Hoxs64, etc. such because they only support a single density for each track.

until today noone could provide a single image where this matters at all, so this isnt really as important as you want it to be. the handful titles that use more than one density on one track work just fine when the right GCR data is in the G64 (which it has to be in any case). the titles where existing G64s (mostly created with mnib) didnt work could all be made work by properly converting them from a kryoflux dump. thread

wolfgang: forgot this (load to georam and start by SYS 57000)

87 (edited by JimDrew 2014-10-31 14:31:49)

Re: C64 core talk

There are no fewer than 10 different devices that support d64 images, perhaps you are living in a cave!  smile. The Chamelon's drive emulation is worse than WinVICE.   There are some g64 images of the various programs that require multiple densities per track, and they aren't magically fixed by dumping them with KryoFlux.  The KryoFlux team and WinVICE team have stated that they don't care about these programs, at first stating that they didn't really exist... clearly that is not the case.  I don't want to see another C64 emulation with half-ass support for important features.


Re: C64 core talk

JimDrew wrote:

I have all of the info on the G64 format if you need it.  If you plan to implement G64 support, please consider supporting a density level for each and every byte of data.  The G64 format allows for this, but it is not supported by ANY emulation system ever made.

Yes, I saw in the descriptions that there are two sections, I assume you mean the "speed zone block" which can be optionally set via a file offset in the "speed zone area" (instead of a single speed value for a whole track as you mentioned). I think Mikes fileio implementation allows to have two channels of one file, so it should be possible to read the gcr data and the speed zone data in parallel if it exists (that's an assumption for now - for this I need to dig deeper in the fileio library code from Mike  big_smile ).

For now my first step will be to get a "minimal" g64 reader working via fileio (reading the different tables and using them to provide the proper data from the file selected via OSD). The g64 support should also support writing, not only reading. I intend to do it in hardware (= on the FPGA), maybe it will be a good idea to use another microblaze for this task. And yes please, if you have an example g64 which uses this additional speed data blocks, this would be very helpful to check it out and set it up correctly. Independent if it is really needed or not - it is a proper technical challenge to solve with the Replay setup wink



Re: C64 core talk

gpz wrote:

wolfgang: forgot this (load to georam and start by SYS 57000)

Thanks, I got it. My problem is that I am not sure what the loader at $DEA8 (should be the first block after reseting the block/page register) - which copies itself to $1000 - requires afterwards. I assume it loads $060C00 in the georam.

I did this and starting after an upload of the RAM image still fails. When using the loader directly from the d64 disks it works fine (as it directly uploads and starts afterwards). I have not found any doc about the ramdrive format yet (which I assume is also used for this game image), so it is hard to debug / check if the block order I upload is somehow wrong (which is my assumption for now) - I need to disassemble the stuff first to check what it does. I already checked with schematics I found for neoram and georam and it should be identical...

Will dig further, how hard can it be wink



Re: C64 core talk

Something which bothers me is my monitor I am using, its an old one and not so easy to use...

Can someone propose a good monitor/debugger for the C64 which can (ideally) directly load as ROM/RAM image (I want to have it available immediately at reset, not mandatory but less pain when reseting the core all the time for experiments) and maybe also has some support for e.g.  "clear text" information on I/O register contents and so on (I hope you know what I mean), beside the usual single step, register/memory watch, etc. functions?

Thanks!  wink


91 (edited by JimDrew 2014-11-01 18:19:41)

Re: C64 core talk

I looked at the scroller code today.  It's a VB routine that inserts itself into $0314/$0315 and also disables the NMI (prevent RUN/STOP-RESTORE from working).  That code just sets the background and foreground colors for certain parts of screen based on table values.  It's pretty simple.  The code is EXAMPLE, and it is loaded ,dv,1 to $C000.  The program MAIN is BASIC, but it was not compiled.  I guess I stopped doing that sometime in the middle of Supercard+ (Supercard's main program was always compiled) due to the lack of disk space needed to store the DTL runtime library.  So, you load MAIN, dv and look at the code.  The EXAMPLE program has a couple of nice features in it - one of which is to determine what version REU (if any) is being used.  I am looking for the source for this.  I have literally hundreds of disks containing source code to everything I worked on (which ended being more than 60 commercially released titles for the C64/128).

92 (edited by JimDrew 2014-11-01 22:16:40)

Re: C64 core talk


Here is the VBI code.  I couldn't find the original assembly so I disassembled it so you can take a look.   If you load EXAMPLE, dv,1 you can SYS49408 to see the scrolling colors.  If you press RUN/STOP, 1, or 2 it will restore the VBI and NMI vectors and exit.    By the way, "dv" = device (i.e 8, 9, 10, or 11).  The code at $C100 (SYS49408) is not shown, it just invokes the VBI/NMI, increments the color table and checks the keyboard.

        * = $C000

        JMP KillVBI
        JMP $C0CA

InitVBI    SEI
        LDA #<VBCODE
        STA $0314
        LDA #>VBCODE
        STA $0315
        LDA #<NMICODE
        STA $0318
        LDA #>NMICODE
        STA $0319
        LDA #$00
        STA $DC0E
        STA $AE
        STA $40
        LDA #$01
        STA $D01A
        LDA #$1B
        STA $D011


        LDA $DD08
        LDY $AE
        LDA COLORS,Y
        STA $D020
        STA $D021
        LDA LINES,Y
        STA $D012
        INC $AE
        LDA $AE
        CMP #$0E
        AND #$00
        STA $AE
        STA $D019

COLORS    .BYTE 0x00
COLOR1    .BYTE 0x03
COLOR2    .BYTE 0x0E
        .BYTE 0x06
        .BYTE 0x04
        .BYTE 0x0E
        .BYTE 0x03
        .BYTE 0x01
        .BYTE 0x00
COLOR3    .BYTE 0x06
COLOR4    .BYTE 0x0E
        .BYTE 0x03
        .BYTE 0x01
        .BYTE 0x03
        .BYTE 0x0E

LINES    .BYTE 0x30
        .BYTE 0x32
        .BYTE 0x35
        .BYTE 0x37
        .BYTE 0x3A
        .BYTE 0x3D
        .BYTE 0x3F
        .BYTE 0x41
        .BYTE 0xE0
        .BYTE 0xE2
        .BYTE 0xE5
        .BYTE 0xE7
        .BYTE 0xE9
        .BYTE 0xEC


Re: C64 core talk

Thanks for the code. Will have a look, unfortunately I am a little busy with other topics the next few days...

Moved the G64 file support discussion to here...


94 (edited by WoS 2014-12-26 22:40:36)

Re: C64 core talk

I fixed the issue with the VBI lines generated by the program above. Funny thing is that it was not at all a VIC issue, but caused by a wrong reset state of the CIAs. After a reset, the TOD counter of the CIA shall not run, so the lines in the VBI code
        LDA $DD08
have no effect (the register is always 0). As soon as the TOD counter is started, the VBI code is not working correctly anymore and cause the issues seen on the replay c64 core - as the interrupt routine gets disturbed by this TOD check. I suppose the idea was to change the speed of the colour bar scrolling with this. But for this it should only control the increment of the index to the two lists, basically before
        INC $AE
        LDA $AE
        CMP #$0E
and jump to NORESET. Then it works fine as it still generates the VBI lines in every frame - it just scrolls slower (and only if the TOD is activated before). But better is probably to remove this check of the TOD register completely...

It can be reproduced on any real c64 or emulator when running any program using the TOD  (or just by e.g. writing a value to $DD08) before running this VBI code (and without a HW reset of the C64 / core between).

So it did cost some time to track it down and the code fragment shown was a big help, as I looked at the complete wrong place and I was not aware that the TOD is not running after reset.    big_smile   The fix finally was finally very simple (a single reset value changed) - it is already checked in the SVN for testing.

EDIT: @Jim: currently the additional 1541 memory (which I had in the early experimental hack of the core) is not included in the actual core I checked in. If you can provide me the exact/complete memory map of the supercard hardware you have for the 1541 (either just the complete memory map or a sketch of the changed address decoding schematic of the modified 1541), I can provide an exact HW setup for the 1541 on the Replay core (with enable/disable function via OSD).


95 (edited by JimDrew 2014-12-27 03:35:46)

Re: C64 core talk

Supercard+ has 2K of ROM @ $1000 and 8K of RAM @ $6000.

The ROM file is 8K in size, but only the 1st 2K are decoded and used.


Re: C64 core talk

How do you exactly decode this extra ROM/RAM?

I ask because the original 1541 HW only use adress bits 15,12,11 and 10 for decoding of its two RAM and VIA IC, so this areas are blocked by shadowing of the memory and via blocks:

ram1: 0??0 00mm mmmm mmmm = $0000 to $03FF (shadow starting at $2000,$4000,$6000)
ram2: 0??0 01mm mmmm mmmm = $0400 to $07FF (shadow starting at $2400,$4400,$6400)
via1:  0??1 10 ??   ????    rrrr    = $1800 to $180F (shadow every $10 byte and also starting at $3800,$5800,$7800)
via2:  0??1 11 ??   ????    rrrr    = $1C00 to $1C0F (shadow every $10 byte and also starting at $3C00,$5C00,$7C00)

So I suppose you also change the original decoding on the original PCB to block these blocks from interfering with your additional RAM/ROM?

In the experimental code I did a full decoding of all parts (and thus had no more shadowing at all, which I assume is not accurate enough compared to your real HW setup).


97 (edited by JimDrew 2014-12-28 04:45:36)

Re: C64 core talk

You definitely need 100% exact memory map for compatibility.  It didn't take long for programs to start checking the drive memory map (sometimes in the middle of a game), making sure that there isn't any extra hardware in the drive.  I had to change the Supercard board to make one that could be disabled (Supercard+).  I also added the 2K of ROM code for most of the drive routines used for copying disks.  This also prevented my competitor from stealing my code because it wouldn't fit in the normal drive RAM.

Supercard+ decodes just its 2K ROM at $1000-$17FF and 8K of RAM at $6000-$7FFF.  Everything else is untouched.  The switch pads on the board could disable the decoding completely so it disappears.


Re: C64 core talk

Sorry, does not really answer my question. I would need both parts, the decoding for the additional memories and the changed decoding of the remaining memories on the 1541 board to implement it 100% correct.

Can you provide me the schematics of this extension board and connectivity to the 1541 board just for the decoder part? The rest I can figure out myself...


99 (edited by JimDrew 2014-12-28 18:39:10)

Re: C64 core talk

I don't think I have the schematic for the board anymore, but it is pretty simple.  It used two 74LS138 ICs and one 74LS157 IC, 8K of static RAM, and 2K of ROM.  Actually, a 8K ROM (2764) was used, but only the 1st 2K was decoded.

The ROM is at $1000-$17FF, which is A12 -> A12/A10/A9/A8/A7/A6/A5/A4/A3/A2/A1/A0.
The RAM is at $6000-$7FFF, which is A14/A13->A14/A13/A12/A11/A10/A9/A8/A7/A6/A5/A4/A3/A2/A1/A0.

The 6502 was removed from the socket and placed on the Supercard+ board, and the board plugged into the 6502 socket.  So, I had complete control of the address lines going to/from the 6502.


Re: C64 core talk

I know how to decode the two adresses for the new ram/rom, that is not my problem. I asked about the remaining decoding of the 1541 board. E.g.: how do you disable ram/via access on the 1541 board only for $6000 and keep mirroring for the other 3 combinations for the existing ram/via? This costs some logic to set it up that way (the LS138 do not have open drain to do a wired-and of the low-active outputs). Or is there no more mirroring of these if the additional RAM/ROM is enabled?