TMF Hg
changelog
- Fri, 18 Jan 2013 17:18:50 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Fri, 18 Jan 2013 17:18:50 +0000] rev 129
- [memory] Emulate main memory read wrap-around
3B1s with 512K or 1MB of base memory have a decoding quirk which causes reads
to 'wrap around'. That is to say, on a 512K machine, reading from addresses 0,
512K, 1024K or 1536K will address the same RAM byte. On a 1MB machine,
addresses 0 and 1024K address the same RAM byte.
Emulating this incorrectly causes P4TEST to report an incorrect amount of
available base RAM.
- Fri, 18 Jan 2013 17:03:48 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Fri, 18 Jan 2013 17:03:48 +0000] rev 128
- experimental memory mapper, not quite working
- Wed, 16 Jan 2013 00:41:51 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Wed, 16 Jan 2013 00:41:51 +0000] rev 127
- fix default HDD sectors-per-track
The 64MB Micropolis drive we're trying to emulate in FreeBee has 17 sectors
per track. Fix this in main.c to avoid tripping the sector range checks.
- Wed, 16 Jan 2013 00:40:18 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Wed, 16 Jan 2013 00:40:18 +0000] rev 126
- [wd2010] allow seek delay to be overridden at compile time
- Wed, 16 Jan 2013 00:38:13 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Wed, 16 Jan 2013 00:38:13 +0000] rev 125
- [wd2010] properly constrain R/W ops based on end sector
- Wed, 16 Jan 2013 00:36:51 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Wed, 16 Jan 2013 00:36:51 +0000] rev 124
- [wd2010] display 'number of sectors' for sector R/W ops, display WrLBA in bytes not sectors
- Wed, 16 Jan 2013 00:35:10 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Wed, 16 Jan 2013 00:35:10 +0000] rev 123
- [wd2010] fix confusing expressions used for multisector mode
- Wed, 16 Jan 2013 00:34:11 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Wed, 16 Jan 2013 00:34:11 +0000] rev 122
- [wd2010] use size_t for init filesize, make disc init more verbose
- Tue, 15 Jan 2013 17:02:56 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Tue, 15 Jan 2013 17:02:56 +0000] rev 121
- Implement m68k_read_disassembler_* properly
The previous implementations of m68k_read_disassembler are unsuitable due to
interactions with the memory mapper. A read from memory by the DASM should not
mutate system state.
So we modify the m68k_read_disassembler_{8,16,32} functions to do the memory
mapping themselves without causing page faults (bus error exception) or
updating the page flag bits (which could really upset the kernel).
Now all we need is a debugger/disassembler...
- Mon, 14 Jan 2013 09:50:37 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Mon, 14 Jan 2013 09:50:37 +0000] rev 120
- Max out system memory by default
Set the system memory to 2MiB base, 2MiB ext. This is a fully loaded 3B1
motherboard with a RAM expansion board. 512KiB base/no ext is the minimum
which can be specified (e.g. kernel memory map area only) but does not leave
any room for userspace. The kernel doesn't like that and doesn't handle it
gracefully...!
- Mon, 14 Jan 2013 09:48:21 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Mon, 14 Jan 2013 09:48:21 +0000] rev 119
- Handle memory more gracefully
Fixed in this cset:
* Return an 'empty space' value if the memory wraps around
* Allow the 'empty bus' value to be changed via an ifdef
* Properly handle situations where expansion memory is turned off
- Mon, 14 Jan 2013 09:22:12 +0000
- by Philip Pemberton <philpem@philpem.me.uk> [Mon, 14 Jan 2013 09:22:12 +0000] rev 118
- More bus error fixes for FreeBee
I have fixed two more bus error handling bugs in FreeBee. First, the CPU core was executing the instruction regardless of whether a bus error occurs when fetching the opcode (which caused it to execute a bogus instruction in such cases). The other one was related to one of my previous fixes - the jump to the bus error vector was at the beginning of the main loop, so it wouldn't be called immediately after the bus error occurred if the timeslot expired, causing the return address to be off.
With these fixes, Unix now runs enough to get into userspace and run the install script (it is also possible to break out and get a shell prompt). However, many commands segfault semi-randomly (or more specifically, it seems that some child processes forked by the shell might be segfaulting before they can exec the command program), so installing the system isn't possible yet. I am not sure exactly what the bug is, but it seems to be related to some function in the shell returning null when the code calling it is assuming that it won't. What the function is, or why it is returning null, I'm not sure (the shell is built without the shared libc and is stripped, making identifying the function harder). I suspect that the function might be in libc, but that is hard to tell.
Author: Andrew Warkentin <andreww591 gmail com>