Cart with network server?

[christo]

Hi All,

I've read a lot of threads here from over the years and the card projects are very impressive.

My dream is a cart that I can remotely update so that the "ROM" (flash?) contents change on demand, controlled by a development machine on the network (or over serial). I'd like a real-hardware cross-development system which doesn't involve inserting an sd card twice for every deploy cycle. The perfect realisation of this would mean I do not need to touch the VIC to update the code it runs.

The typical use case of seemingly everyone else is to load an SD card with desired binaries and go. I wouldn't be surprised to learn that developers either code on-system (Monster looks amazing) or do cross-development with an emulator.

What is the best existing cart for this? If none exists what would it take to make it? Seems like the EasyFlash has a USB connection that can be used to update the flash.

I recently got a Sidekick64 with VIC-20 Adapter. This uses an attached Pi running a baremetal kernel ("Circle", not a full Linux OS) which updates flash contents which the VIC then loads like any cart. https://github.com/frntc/Sidekick64

I'm aware of the alternate firmware/kernel for Sidekick https://github.com/hpingel/Sidekick64 which adds network support but there are some scary warnings about cooking the pi trying to run the network server. It may be fine, I'm still investigating this.

Ultimem also looks like an option - the one with a serial port. I have to admit I'm very confused by the information about this project I have found so far.

I suppose an alternate workflow is to load a bootstrap cart into, say, Sidekick 64 which loads the latest image over a wifi modem or some kind of serial hookup. This way resetting the VIC could load the latest build.

So the broader question is if there is no cart that is good at this workflow, what would you people suggest?

[christo]

I should say, it doesn't need to be a "server". Implicit in one of my examples is the VIC-20 being more of a client.

[Schema]

You could use a Meatloaf network IEC device (which works great on the VIC!) . It's not commercially available yet, but you can build your own easily with about $15 in parts.

https://meatloaf.cc/
https://github.com/idolpx/meatloaf-specialty

You could then point it to an accessible folder where your build environment puts the binaries, and load them from there. You'd still need to touch the VIC, but with something like JiffyDOS you could get it down to a couple of keystrokes.

Meatloaf also supports WebDAV if you want to push the binaries directly to it.


If you really want to automate the keyboard, you could hack something up with Blue64 potentially:
https://github.com/sideprojectslab/blue-64

[Schema]

Also, if you build your project as an auto-start cartridge image with the proper signature bytes, and put RAM in the appropriate block, you can load the image into that area of RAM.

Then when you do a warm reset, the VIC will think there is a cartridge plugged in and auto-run the code on startup. So you might need to install a button, or you could rig up a GPIO to pull the reset signal on the VIC motherboard low for a second.

[brain]

I actually have a project on the bench that should handle this.

It's an esp32 on a PCB that plugs into a 28pin EPROM socket.

The idea is that the esp32 connects to the local WLAN and presents a TFTP (or something, code is not written for this) server to the world. The developer then compiles/assembles their code and runs a tftp "put" of the resulting binary into the esp32, which then dumps the data onto a built in 512kB SRAM on board.

As one of the last things it does after loading the RAM, it then optionally triggers the RESET line (either active high or low) to restart the device using the ROM.

So in the case of the VIC-20, put the little board on a simple EPROM cart, and clip the reset line to the reset line on the cart. Set the RESET trigger to active low, dump an autostart cart image to the tftp server, and presto, no hands real hardware development target.

I made it a 28 pin EPROM so it could be used for lots of platforms, not just the VIC, but you could optimze the design onto a cart directly for VIC specific operation.

Jim

[Mike]

I wouldn't be surprised to learn that developers [...] do cross-development with an emulator.

That's probably the best bet.

You also might want to check out this thread: 1541 Emulation

... and to quote from there:

... around point 3, I am missing the step "(x) check the software in emulation on PC/Mac until most obvious bugs are ironed out".

In that case, the sheer number of full turn-around cycles you're implying here is minimized and most of the development takes place on the PC/Mac only. Of course this requires you have an up-to-date emulator installed on your big machine, are willing to use it, and you trust its emulation capability.

Emphasis added.

In the end the finished program still has to run the gauntlet of truth on the VIC-20 itself. The real hardware is the reference - and, IMO, it would be a pointless exercise to program for emulation only.

[christo]

Also, if you build your project as an auto-start cartridge image with the proper signature bytes, and put RAM in the appropriate block, you can load the image into that area of RAM.

Then when you do a warm reset, the VIC will think there is a cartridge plugged in and auto-run the code on startup. So you might need to install a button, or you could rig up a GPIO to pull the reset signal on the VIC motherboard low for a second.

This sounds great! I'm checking out Meatloaf.

[christo]

I actually have a project on the bench that should handle this.
...

I made it a 28 pin EPROM so it could be used for lots of platforms, not just the VIC, but you could optimze the design onto a cart directly for VIC specific operation.

Jim I like the sound of this! How do you handle the updates? I am very ignorant of electronics but I would have thought you need to reset the host machine before updating the RAM or the memory could be read in a weird state?

[christo]

I wouldn't be surprised to learn that developers [...] do cross-development with an emulator.

That's probably the best bet.
...

In the end the finished program still has to run the gauntlet of truth on the VIC-20 itself. The real hardware is the reference - and, IMO, it would be a pointless exercise to program for emulation only.

Mike thanks for the reality check.

[brain]

I actually have a project on the bench that should handle this.
...

I made it a 28 pin EPROM so it could be used for lots of platforms, not just the VIC, but you could optimze the design onto a cart directly for VIC specific operation.

Jim I like the sound of this! How do you handle the updates? I am very ignorant of electronics but I would have thought you need to reset the host machine before updating the RAM or the memory could be read in a weird state?

You could hold the machine in reset state while updating the RAM.

Jim

[Schema]

The idea is that the esp32 connects to the local WLAN and presents a TFTP (or something, code is not written for this) server to the world. The developer then compiles/assembles their code and runs a tftp "put" of the resulting binary into the esp32, which then dumps the data onto a built in 512kB SRAM on board.

This sounds super cool, I would also love to learn more. (I messed around with dual-port SRAM with an Arduino and it never worked properly.).

Could this also control lines like GAME/EXROM/ROMH/ROML/IO2/IO2 etc on the C64 cartridge port?

[Orangeman96]

chysn (4/18/1971-2/20/2024 — may he rest in peace) was working on something called wAxfer -- a wAx plugin to allow Bluetooth® transfer to the VIC-20 -- before he was taken way too early from us. Maybe that can be adapted to Wifi, similar to a Strikelink? -OGM

wAxfer

[christo]

...

You could hold the machine in reset state while updating the RAM.

Jim

Excellent thanks Jim. Chat gippity said I could do that but I was suspicious. Happy to hear confirmation from an expert.

christo

[christo]

A bit of background in case anyone is curious. I'm not merely trying to avoid wear and tear on the SD card contacts in the retro-programming code-build-test loop. Mike made a good case for focusing on the emulator target in such cases.

Exploring VIC-20 development after decades, I'm aware VICE is a very faithful emulator, but I'm also curious about that enigmatic gap between emulation and real hardware, particularly around video and audio. Just curiosity, no big commitments. I'm also working on a few tools - disassembler, assembler, emulator etc. These are babies. I'm under no illusion that my efforts could compete with venerable projects like VICE.

One motivating idea for "inner devloop" with real hardware (apart from retro authenticity aesthetics) is to explore the use of machine learning in program synthesis. I'm wondering if it's possible to build an automated feedback loop with both emulators and real hardware executing the same generated code. I have a half-built rig for programmatic control of audio/video capture for the hardware (which has plenty of gotchas itself) and I'm assuming the emulator equivalent is trivial with screen caps. I'm hoping I can improve my understanding what multi-modal AI models can do by giving such a system the ability to write, execute, compare results and modify the code accordingly. Inevitably I'm having to improve my understanding of the VIC-20 too.

One example application is to automatically identify machine code idioms in the available library of games and demos that are most likely to produce audio and video that is perceived most differently on real hardware. I can imagine a lot of other interesting applications for this.

It could all be beyond my skill but I'm OK with that.

[christo]

chysn (4/18/1971-2/20/2024 — may he rest in peace) was working on something called wAxfer -- a wAx plugin to allow Bluetooth® transfer to the VIC-20 -- before he was taken way too early from us. Maybe that can be adapted to Wifi, similar to a Strikelink? -OGM
...

Thanks for the tip. My reading of wAxfer suggests this would Just Work™ with USB serial.

Sorry to hear about chysn. I have come across his work in the past.