In testing for emulation bugs, it seems storing the world map on drive 9 caused many problems.  Disable drive 9 & the bugs go away.  There are some hints that Vice doesn't faithfully emulate the serial bus.  

https://www.lemon64.com/forum/viewtopic.php?t=74765

Despite having blanks for 4 drives, there's no evidence anyone uses dual drives in vice.

A quick test in GEOS failed to access drive 9.  Drive 9 has to be disabled or it'll get stuck looking for desktop 1.5.

Then after enabling it, you have to run the configure program. 

The configure program can't detect it.  Drive 9 worked with standard kernal I/O but not with any kind of fast loader.  So the world map for testing needs to be in the same .d64 image as the program & a maximum world map is going to require a disk swap. 

So in addition to the lack of physical I/O signals, emulation is going to involve compromises in terms of peripherals.  An FPGA emulator accessing drives through physical I/O signals might still work.  Of course, 1 drive is a more accurate representation of what young lion had.

-------------------------------------------------------------------------------------------------------------------

Some  testing showed when ATN is low, the drive always reads low voltage from DAT.  When ATN is high, the drive properly reads DAT.  That's not supposed to happen.  It could be yet another emulator bug.  Given limited time & tools, there could be a way to pulse ATN just for synchronization & neglect the printer state.  The debugging problem ended up being hard enough to settle on just blinking binary on the LED.  The lack of logic probing & endless obscure emulator bugs consumed such a vast amount of time, they put a real emphasis on doing the least that could work.

Big surprise, the Steil fastloader didn't work in emulation.  Then came a few attempts at simple bit clocking.  Driving CLK from the drive was slower than driving it from the host.  Sending 1 bit at a time seemed to be the faster way, since a lot of bit fudging is required to pack 2 bits at a time.  Using ATN as a clock had a problem where DAT changes at the same time ATN changes, so 2 bits at a time really have to free run.

Once the many issues were finally resigned to emulation bugs & the fastloading settled on clocking 1 bit at a time, the rest came together pretty fast.  Concurrent scrolling & disk reads with the fastloader were lightyears ahead of the stock ROM, even with single bit clocking.  Concurrent I/O will always have an impact to the scrolling, but it seems to be reasonably imperceptible now. 

Sector reads with seeks of 1 track ran at 1 second.  When it seeked 4 tracks, it took 1.2 seconds.  Scrolling goes at 9fps during the data transfer.  The stock ROM needed 2.4 seconds per sector with 6fps.  If it's not reading the disk, scrolling still goes at 9fps.  The impact is not detectable in a screenshot.  It's intriguing how little time is spent bit banging the serial port.

Attention turned to manetaneing a tile database in RAM.

----------------------------------------------------------------------------------

The double buffered bitmaps suck 20,000 bytes.  By packing the color memory, each tile sucks 2500 bytes.  It takes 4 tiles or 10,000 bytes to render the current view.  At least 12 more tiles or 30,000 bytes have to be offscreen to scroll in 4 directions without stuttering.  It became clear that wouldn't fit in 10 year old lion's commodore.  2 offscreen tiles are the minimum & would leave roughly 30,000 bytes free.  It could scroll smoothly 1 way.  Any change in direction would usually cause it to stutter.  Sometimes the player would get lucky.  It would be even luckier if 4 offscreen tiles fit.  Then the stuttering would only happen in 90 degree direction changes.

The general idea is to have an age for each tile & load the next 2 tiles based on the player's heading.  Ideally, instead of stuttering, it would draw black while a tile loads.  This requires it to redraw the entire screen after the tile loads, creating a stutter.  It needs a full screen redraw anyways when it starts.  Eliminating double buffering would free up 3 more tiles.  The great escape didn't double buffer but also cropped down to make it more bearable.

A combination of world scrolling & player movement seems inevitable.  When a new tile isn't available, the player just moves across the screen.  Then there's a warp back to the center when the tile is loaded or a freeze when the player hits the edge.  Frame rate is probably going to max out at 8 or 7.  It could be pretty unbearable to move the player.  Some ideas 40 years ago involved not scrolling until the player was 1/4 screen from the edge, but it wouldn't provide much look ahead. 

Then there's the option of abandoning scrolling.  When the player gets to the edge, load 1 tile on demand & redraw the screen.  Police quest for DOS worked this way.

Most games in those days just scrolled left & right, in which case it would be a rail shooter.  It would never stutter & just need 3 tiles in RAM.