Denial

your programs could be 50x smaller and 1000x faster with assembly Ok, I'll bite. While you probably can do the main loop under 100 cycles you can't make the C64 program below in 14 bytes: 0 poke56325,255:gosub30:u=81:b=0:s=1064:j=56320:f=63:l=2023:g=4:w=8:a=960:n=3 1 printchr$(142)"{^h}{clr}{r...

So it is / was good practice to connect them all to one of those to avoid stray signals, chip damage etc. Just inputs, as trying to force VCC/GND to different state with TTL output will fry the chip. If you tie TTL input to ground you will waste more current than when you tie them to VCC. That's be...

brain wrote:Done.

Well, he could do even better if he tied unused inputs to VCC or ground. Not as crucial with TTL as with CMOS, but still a good practice.

I blink lights. There is considerably more blinking to do now, picture was taken a year ago. Since then the first five racks have been filled up almost completely.

carlsson wrote:The chain of build could even include c1541 to automatically push the files onto a D64 image.

The last time I tested c1541 it saved files with interleave 1, making loading extremely slow on real hardware and on VICE too if true drive emulation is enabled.

No need for D71/D81 just to play the game. From my earlier post : There is enough free sectors on tracks 17 and 16 for the interpreter, so you don't need to swap disks except when saving and restoring. Beta versions use separate prg for interpreter and D64 for data because only the first changes. Yo...

OTOH: why change software and risk adding new bugs when there is a tested hardware solution?

Mike wrote:Iwhy you didn't settle on a bigger format (*.d71 or *.d81) in the first place.

To keep it usable on real hardware if someone wishes to have an ultimate oldschool-experience.

Orion70 provided me with enough information, so I could make sure, that the method I described above would work: The game disc data is mirrored in a CBM partition on a *.d81 file, and the interpreter itself is copied over as regular file. ... That alone does not do much good as far as saving is con...

By the way...I must apologise to TNT for sort of "crapping out" on the beta-testing for the infocom interpreter for VIC. No problem, I'm 99.999% sure that V3 code works now. I wish I had time to add game save/restore which is the only important thing missing, fastloader / FE3 support woul...

sd2iec related: I didn't find a method to activate swap list disk changes with software. CD:_+ and CD:_- would be just fine for my purposes ;) Why? Beacuse Infocom games don't usually have enough space for save files on data disk, and I guess most FE3 owners have not installed disk change buttons. ...

sd2iec related: I didn't find a method to activate swap list disk changes with software. CD:_+ and CD:_- would be just fine for my purposes ;) (_ denotes back arrow) BTW: I had to reset FE3 before bootloader managed to load firmware from memory card. Maybe my SD card wasn't initialized fast enough? ...

Is VIC-20 Block 0 ($0400 - $0fff) mapped to SRAM Bank 0 in SUPER RAM mode? Documentation says it's enabled but doesn't specify where it's mapped. edit: Second question - is there a way to get name of current directory or mounted disk image? I'm thinking of scenario where I might want to CD:<- , do s...

Pedro Lambrini wrote:That would be very cool. All sorts of interesting things could be done with that. Maybe even the Infocom interpreter could arise from the grave...

You mean that one which is bound to get some final expans... errr... final features now that the author has a new gadget to play with?

Whatever you decide to do, keep the original 1:1 noncropped screenshots in safe place so you can change your mind later.