Menu
▾
▴
#2181 Infinite loop.
This is using the latest release (r45883 snapshot)
I'm trying to run some code that seems to use some sort of custom disk read/write routines that cause an infinite loop. I believe it is related to how the 1541 emulation works, specifically the IEC data lines, or possibly something with CIA emulation.
The code involved (used often in this old application) is:
2238: BIT $DD00 ; read hardware bits 7 and 6
223d: BPL 2238 ; stay in loop while bit 7 = 0
223f: BVC 2238 ; stay in loop while bit 6 = 0
Using true drive emulation doesn't fix this, nor does any of the 'idle method' options in the drive section. I'm pretty sure I've tried every option available in Vice at this point with no luck.
I'm not good with 6510 assembly or anything so tried to use ai for my information.
From chatgpt (my apologies... ):
it looks like this is "IEC bus idle-state detection"
For the loop to terminate:
ATN must be HIGH (bit7=1)
CLOCK must be HIGH (bit6=1)
But VICE does not set these bits high unless:
Device 8 is enabled, and
It has an active IEC bus state machine, and
No disk commands are in progress, and
True drive emulation is ON, and
The IEC lines are at idle in the emulated 1541.
If ANY of those fail → the bus is treated as not idle → loop is infinite.
Why real hardware doesn’t do this
Real IEC bus lines float HIGH (pulled up by resistors) unless:
CPU asserts ATN
Drive asserts CLK/DATA
Another device asserts lines low
Without bus activity → idle state = all HIGH.
Your loop becomes infinite because VICE is not simulating the IEC bus lines, so $DD00 bit 7 and bit 6 never go high. Enable True Drive Emulation and disable Virtual Device Traps to fix it.
Using the monitor and stepping through the commands where the program freezes, I can see that it is definitely looping on this code.
So, technically I'm not sure if this is a bug or a feature request.
I guess what I'm hoping for is some way to resolve this issue, whether that be a workaround or a setting that alters the IEC bus line behaviour?
Do you have a complete test case for this? ie a program we can run that shows the broken behaviour?
Sure. It's old BBS software.
You'll have to set up a tcpser connection before it will initialize. The software queries the modem right at the start and won't continue until it sees a response. I'll attach it here, I guess? let me know if you want the tcpser init string that I use along with the ip232 settings that seem to be required.
Once you mount the disk, you'll have to load "set up" and create a data disk.
After that's created, you can run "blue board up" and follow along.
thanks in advance for your efforts.
Can you tell when exactly it hangs? (using tcpser is no problem, i have fiddled with other BBS stuff locally before when debugging RS232 stuff)
It hangs whenever it tries to access the disk, after you've run the program and entered the date/time etc.
You can call in as a remote caller, and after entering "y" to the linefeed question it will try to access the disk to display a bulletin and crash.
If you didn't enable the bulletin it will crash right after you create a new account when it tries to access the disk. Seems like any sort of disk access will get hung up.
CTRL-D from the waiting for call prompt should offer a way to exit gracefully and save data, and it hangs there also.
Somehow i cant even run it... it only does a warmstart (like run/stop restore) whatever i do (this is with rs232 configured for userport rs232)
please give me some instructions :)
omg you've made it worse! juuuust kidding lol...
let's see...
so, assuming a default config with the 64 emulator, x64sc or whatever the binary is called... (not at my computer).
you should be able to just change to 1541 drive (presumeably 1541ii would work also),
enable rs232 on one of the ports, set speeds to 300 baud. nothing else, just a fresh NTSC machine.
have tcpser running with the basics, -v 25232 - p 6400 -s 300 -S300 -l 4 -t mM -i"s0=0"
Insert the 3.1 disk, and load "set up" to create the data disk. attach a blank .d64 disk. (I've tried the other formats also). I usually warp through these long bits but not always...
re-insert the 3.1 disk, and load "blue board up",8.
select 3 for hayes, y and y for voting/xfers (not important I wouldn't think, does the same with no and no)...
load "blue board up",8 and run it.
that should bring up the waiting for call screen where you're asked to insert the data disk. after that you'll be prompted for dates and times and then you'll be waiting for call.
sys2072 will get you back in if you do a run/stop-restore or cpu reset. (or after saving the data with CTRL-D).
Is there anything new with those instructions, or is that more or less what you were doing? I've never witnessed it behaving the way you're describing.
Last edit: finglonger 2025-12-10
Thats a lot of steps to reproduce the problem.... could you at least prepare those disks? Preferably using a single disk, that i can just autostart?
Somehow i cant reproduce this at all. I made the data disk ok, then when i run the board it prompts for the data disk, and after pressing return it doesnt do anything, no disk acces, nothing shrug