brain

I was coming here to say this. It was an interim step, and I am sure most vendors have dropped the PS2 fallback code in their code by now.

I didn't pay close attention to the description, but I'd assume 50 buffers is 50 256 byte buffers of data (1541 buffer size). If so, that's 12.5K of data, which seems in line with the expansion required (maybe the app takes up 7kB, which leaves about 12kB free for data. Jim

Where are you? Is shipping to disk to me (Iowa, USA) an option? I can dupe it here. If not, do you have someone close who could turn this image into a disk? (https://commodore.software/downloads/download/816-vic20-disk-copiers/15555-vic20-disk-backup) as it looks to do what you want? I can transfer and send if you need... Jim

How big are the files? The unexpanded VIC-20 is going to be tough to use for this. 3.5kB for BASIC, a program will take 1kB, so you're left with 2.5kB at most for transfer, so divide the total file size by 2500 and then multiply by 2 for number of disk swaps 🙂 You don't have a 64 or know someone with one, or a ZoomFloppy?

You can buy sets here: https://www.retroleum.co.uk/vic20screws I have never heard of flat screws being used, so I suspect that's a user add. If you are a purist, you can get the Torx 6.6mm/3.5mm screws at your parts supplier, but I always remove them from any machine I work on and replace with Philips equivalents. The C128 can use the same screws as the 64 and 64C. The only reason CBM moved to TOrx was to push business to the repair centers...

In general, yes (some IO levels, etc.). COde would need to be recompliled, and there is a caveat that might or might not cause issues. 328 and 644 use the standard memory model. 1284 (and larger) have to use "long jumps" to get to some parts of the code. The compiler takes care of all of that, but the timing might be 1 cycle off in certain places (due to needing to fetch another parm before the jump). I can confirm 1284 can use the regular FatFS module (CBM project sd2iec uses FatFS in a 64k/128k Atmel parts. That project also extended FatFS to support VFAT - which I think FatFS does now as well - and ALSO use minimal RAM for FAT buffers [down to 1 512byte buffer in use] Feel free to steal the code if you go down this route) Jim

This is what you are looking for. As others note, SIP is just one use. Single Row 40Pin 2.54mm Round Male Pin Header eBay has lots of hits: https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2334524.m570.l1313&_nkw=Single+Row+40Pin+2.54mm+Round+Male+Pin+Header&_sacat=0&_odkw=sip+header&_osacat=0 If you're not OK with eBay (not sure your need), as Matt notes, Digikey has them as well (they are hard to search for there, but I usually find them after a few tries). FOr my projects, I typically need .6" DIP configurations, so I buy 24, 28, and 40 pin DIP versions of these from overseas sources in bulk (usually 1000 at a time). Not as a plug, but this is what they look like: https://store.go4retro.com/ic-header/ I used to just buy for my own project use, but folks wanted them, so I sell them in singles now as well. But, if you need a large qty, a bulk buy (or going halvsies with someone like me at cost) is a better bet. The DIP style headers I prefer because they sit lower (lower profile), but stocking all the DIP sizes is not tenable, so the single row headers are good to have in the parts box for an arbitrary DIP 32, or DIP 16 thing I need. I know the OP is not asking this, but if someone stumbles on this thread later, note that these will *NOT* work on the TMS9900, as I believe it's a 64 pin .9" pin spacing socket. I can get those in DIP format if a big enough demand is there, but the min qty is 5000 units.

Yay!

Dang, I forgot about that. You are most correct, apologies for that as well. Do you have a way to recompile the code? If so, you can alter the dev in the code for now, while I work on the issue. Eitehr st is failing silently, and the code never gets called, or the parse_equate is broken. Jim

I used my comment as well, but I think my comment is wrong. Since st works, try just doing open #255,"20.de=21" I checked the source and there is no "set" or "se" in the entire source, so I must have decided to punt and just make the parms verbs themselves. My apologies. If your test works, I'll update the code. For anyone who cares: (main.cpp) The main parser reads the hex data, and determines the operation is open, and to the serial device. It checks the registry that every specific soft peripheral registers with (registry.cpp) to find an entry to device 20. It finds the serial.cpp library, so jumps to that. IN serial.cpp, there is ser_open(), which does the open. To ensure compatibility with HEXTIr's way to handling configuration when using the drive peripheral, where an open of some text would normally try to open a file with that name, the code (line 342) checks for channel 255. If found, it immediately starts parsing config, but otherwise, it drops down and tries to do an actual open of a serial part, but it also handles configs there as well. Both branches call ser_exec_cmds(). ser_exec_cmds() (line 279) tries to break apart the string into pieces, and then it sends each piece to ser_exec_cmd() (line 87) ser_exec_cmd tries to match the first few letters of the command to one of two lists, shown in lines 61-85. A cc40 list (b, .ba, d, .da, etc.) and a ti list of additional items (.tw,.nu, etc.). if the command is not in the first set, then it drops into the default case (line 251) and checks the second set. if that list doesn't work, it then calls hex_exec_cmd() in line 273 hexops.cpp contains the default config helper function, hex_exec_cmd() line 306. Just like in serial.cpp, there is a list of commands about the function, as @Vorticon shows. de and dev are both mapped to command DEV, while st, store are both mapped to STORE. When the command is parsed into EXEC_CMD_DEV or EXEC_CMD_STORE, the switch statement in lines 327-342 kicks in. If CMD_ST is found, do it. Otherwise, the code assumes its a "cmd=value" pair, and so tries to parse it. ONce parsed, it checks if the cmd was DEV, and if so, it updates the registry with the new device ID.

I don't think open #255,"se dev=21" will work. THere's no device number in the open statement. Checking my manual, open needs to be : open #<channel>, "<device_number>.<open parms>" So, I think it's open #255,"20.se dev=21" And then the close will fail, because device 20 is gone, but you need to do it to clean up the BASIC pointers. Then, try to open #255,"20.b=9600" should succeed. If the se dev=21 works, then the next step really should be to do open #255,"21.st", which is supposed to permanently store the new device number.

When I do get some time, I'll see if I can strip out all the code and just make a simple test app, that uses some LEDs to test things.

I don't have many that are easy to try. There's debug statements in the code, but you'd need to recompile. A logic analyzer might help as well, but most folks don't have one. You might try grabbing older versions of the code and seeing if that does anything (if it's the shield, it won't, but it might not be the shield). I'm trying to free up some time to get this back on the bench and debug (I was planning to debug the set device command initially), but it might be a week or so, as there's lot in my list to get done first.

Read my comment again. It's "se dev=21" Jim

Someone might have to write some code to do it, but it looks like you open a channel to the rs232 and in the open, use "se dev=21". then, to make it permanent, you'd need to open device 21 and use "st" in the open. But, I'll admit that code is not well tested. Anotehr way to do it is to change the line in serial.cpp and compile and load a new firmware: The line is: https://github.com/go4retro/HEXTIr/blob/51ea22df26cbc6beedb13e90dd0e530246948a9c/src/serial.cpp#L560 reg_add(DEV_SER_START, ser_dev, DEV_SER_END, ops); which can be switched to: reg_add(DEV_SER_START, 21, DEV_SER_END, ops);

You'd need to change the address of the built-in RS232 in the HEXTIr before putting it into a chain. They are no doubt fighting for the address.

Sorry, I will rephrase: To use wd-40 or some other lubricant/alcohol, the ribbon needs to be a fabric ribbon. Alcohol/WD-40 will not work on plastic-substrate ribbons, though plastic ribbons rarely go light from age

I'm sure some may have an issue with this, but I use old ribbons at times, and I take them out and lightly spray wd-40 on the entirety of the ribbon to "loosen the ink up". The first few lines are all smeared, but it does a surprisingly good job of re-invigorating old ink. I think the alcohol in wd40 is what does the job, and so dropping some rubbing alcohol might do the same, but wd-40 is plentiful at the house, spray loaded, and it works for me. It does need to be a fabric ribbon, though. plastic ribbons are out. (But, they typically don't go light from age) (I also have an actual re-inker, which I also use, but I try wd-40 first.) Jim

FOr minimum clearance, I suggest 23128 ROM-el, it's 64kB of FLASH ROM, programmable in a regular programmer: https://store.go4retro.com/rom-el-23128-23256-flash-rom-replacement/

Yep, sorry to burst the bubble 😞 If you can skip by on less than a full screen (half screen, let's say), you might have a chance in an unexpanded VIC. Depending on the use, it might be workable. But, 8-35K expansions are pretty easy to get and/or build now, so don't feel you have to settle.

All of our memory is a bit faulty by this time, but I can explain why it is not possible. The VIC-I IC (which is the GFX controller) has a fixed dot size. So, there is no way to squeeze the pixels. You can expand the length of a line to a certain extent, which will push the borders off the sides. But, the pixel size is constant. So, if you can't compress the font, what about halving the font itself. 4x8 chars to the rescue. Hmmm, there is only a native font capability for 8x8 and 8x16 fonts in the VIC-1. Any other size requires we fake putting text on the screen using a graphics screen. It turns out, there is no graphics mode on the VIC-I (Shocking, I know, but I speak the truth). All games that need a graphics screen have to jump through a weird hoop to put GFX on the screen. The trick is to take advantage of the fact that a font can be 8x16. So, if we pull the borders in just a bit to create a 20x24 VIC screen, and then fill the screen with 240 characters and then turn on 8x16 fonts, we will just cover the entire screen. Then, you treat the 240 8x16 characters in the RAM used to read the font information as your "screen". The math is a bit tricky, given that the cells are 8x16 and so on. Oh, BTW, 240 8x16 characters in a font takes (16*240 = 3840 bytes). That's all the internal memory you have, basically. Just this font and zpage and stack leaves you only 768 bytes to manage this graphics based virtual text screen and have a program, which is not enough. Hence the need for a RAM expansion.

Correct. Sorry, it's both the charm and curse of the VIC

Think of Commodore ROMs in 2 categories: 24 pin 28 pin 24 pin are non JEDEC pin compatible and need an adapter to adapt to 27(X)XX EPROMs or 28XXXX etc. EEPROMs. I could put a shameless plug in here, but the adapter is dirt simple. 28 pin units are JEDEC compatible. So: VIC-20, 1541, C64 breadbin: 24 pin C64C, 1541C, 1551, 1541-II, +4, C16, C116, C128, C128D, C129DCR: 28 pin (I'm somewhat ignoring the PET line, where there are 6540s, 6550s, 6530s, and 6532s, which are completely odd. If you need a 6540, I've got an adapter for that.) I didn't realize ROM switchers are still not ubiquitous, but the 2364 and 23128 Adapter on my site can switch 24 pin and 28 pin ROMs, just add your favorite EPROM and some switches.

A photo might be nice, of all 4 connections. The adapter is a passive item, so I am usure what might be it's issue. I'd also inspect the solder joints, as maybe the assembler missed something. Jim

I'm still having issues with my test environment, but, assuming the latest Arduino build is working, I made the pin mapping changes and recompiled and pushed to the repo. Feel free to try and report back. To address my test env issues, I need to get a logic analyzer on the bus, and that won't happen until this weekend.