The ImageDisk sectsize field was incorrectly set to the number of
bytes in the sector, when it should be an index as follows:
00 = 128 bytes/sector
01 = 256 bytes/sector
02 = 512 bytes/sector
03 = 1024 bytes/sector
04 = 2048 bytes/sector
05 = 4096 bytes/sector
06 = 8192 bytes/sector
Tested disk formatting on MS-DOS 1.25, Cromemco CP/M 2.2,
Cromemco CDOS, OASIS 5.6.
The AB Digital Design B810 RAM card is a 256K Dynamic RAM card
with onboard refresh logic. AltairZ80 support emulates four of
these cards for a total of 16 banks.
As used for the OASIS operating system, the B810 is configured
with common memory at the low addresses (0000h-3FFFh) with 16
banks of 48K from 4000h-FFFFh.
In order to have the common memory appear from 0000-3FFFh, set
the COMMONLOW register to 1:
D COMMONLOW 1
Custom TTL design by Marvin Minsky. There are two displays: one
raster scan for bitmapped characters, and another random scan for
vector graphics. There is also a keyboard, and a UART for talking
to a host computer.
The computer is normally booted off a ROM which reads and starts a
secondary loader from the UART. The loader is responsible for reading
the payload, which comes in checksummed blocks. The LOAD command
accepts files in same format.
Previously, the RUN command would gather and set the desired
PC start address, but then it would invoke the reset logic for all
DEVICEs. The CPU DEVICE's reset routine might reasonably
initialize the PC to a known state which would the overwrite
the PC specified on the RUN command. This change performs
the reset before setting the PC to the specified value (or it's
previous value if no PC was supplied on the RUN command).
SSV ("Scroll Saver") was the Imlac console program and terminal
emulator at MIT's Dynamic Modeling group. It was written mainly by
P. David Lebling. This copy is from Purdue University, courtesy of
Tom Uban. SSV is required to run Maze; the game expects to find SSV's
font data in core.
New sim_video APIs have been added to make it possible for a simulator
to open multiple windows. Two slightly updated functions are:
t_stat vid_open_window (VID_DISPLAY **vptr, DEVICE *dptr, const char *title, uint32 width, uint32 height, int flags);
Like vid_open, but return a dynamically allocated VID_DISPLAY struct
and return it in *vptr.
t_stat vid_close_all (void);
Close all currently opened windows.
In addition, these new functions correspond completely to the old set
of sim_video functions, except the first argument is a VID_DISPLAY
pointer: vid_close_window, vid_map_rgb_window, vid_draw_window,
vid_refresh_window, vid_set_cursor_window, vid_show_video_window,
vid_is_fullscreen_window, vid_set_fullscreen_window,
vid_set_cursor_position_window.
Faster host systems today can get very fast instruction execution rates
for a short duration calibration test. These may be skewed by round
off error, so we now run the calibration for a minimum of 100ms.
This problem only appears when debug output is prodigious. That
prodigious activity is already dramatically affecting timing, so adding
additional delays to allow the debug output to catch up won't
make anything worse.
It appears that we could jump over the C runtime implementation of
fwrite() and do an explicit write() system call and retry that until it
succeeds, but this approach would have two negative consequences:
1) it would jump over other buffered data that the C runtime fwrite()
may have pending due to output produced by other than debug
activities, thus emitting output out of order.
2) Windows doesn't have a direct system call used by its C runtime
for write(), but merely implements write() as part of the C runtime
and as it turns out that write() returns an int vs a ssize_t type
result. An explicit cast could address this, but point 1 would still
be a concern.
As discussed in #957
Previously, the status returned by fwrite() while writing debug output
was ignored and all debug output was presumed to be correctly written.
This change tolerates incomplete writes performed by the C runtime
and retries the remaining writes as long as the retries take.
This change completely presumes that the C runtime fwrite() returns
correct information when the data has not been completely written.
That of course will likely depend on the OS level write function
returning correct informatoin from the write() system call that
fwrite() depends on.
Timing concerns while emitting debug output have always been a
problem since even composing any debug output is likely to be much
more work than basic instruction execution off the current single
instruction. Clock calibration probably will be fundamentally unreliable.
As discussed in #957
