old microcode listings
|
Prev: Software vs Hardware
Next: Searching for the PDP-3
From: Terje Mathisen on 9 Jan 2007 06:49 Peter "Firefly" Lund wrote: > On Mon, 8 Jan 2007, Terje Mathisen wrote: > >> The guy who wrote this entered Caltech a few months later, and then >> started working for Goldman Sachs after graduation, presumably at >> quite a bit above my own starting salary. :-) >> >> Good for him! > > Yes :) > > The wildest thing is that it was actually possible to improve it a bit! > > Instead of using INT 16h to test for a keypress, one could use IN AL, > 60h followed by RCR AL,1 and a JC/JNC. It was also possible to write > some of the interleaved loop stuff such that at least one byte was > shared between instructions, in other words, such as the lower jump > jumps into the middle of an instruction such that the remainder of the > instruction just happens to be another useful instruction. > > Instead of using MOV BH,A0 followed by MOV ES, BX, one could use a POP > ES, I think it was. The top of memory was available at a field inside > the PSP and as far as I recall, it was easy to get it into ES. The top > of memory wouldn't always be A000h but it would almost always be close > enough for the visuals to work just fine. I've studied the 20-byte version as well, it is available at a 'Programming Gems' website (along with a few snippets of my own code :-), I really don't like most of the "optimizations" used to get down to 20: It uses 9FFFh instead of the proper 0A000h as the segment of the video screen, something which does work, but only due to a non-guaranteed value on the top of the stack. Using POP from the stack to initialize the star field crashes if there happens be a timer (or other hw) interrupt while the stack pointer has wrapped around into the PSP+code. I.e. the original 24-byte was elegant, while the 20-byte version was ugly, IMHO. :-) The tightest code I've ever written must be either my combined keyboard/EGA/VGA driver or maybe the code I wrote for executable MIME ascii. The latter uses code as data and vice versa in several levels, while handling text reformatting at various levels, and it stays within the 70+ MIME-blessed chars/bytes that are transparent across all email gateways. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: "Peter "Firefly" Lund" on 9 Jan 2007 10:49 On Tue, 9 Jan 2007, Terje Mathisen wrote: > Using POP from the stack to initialize the star field crashes if there > happens be a timer (or other hw) interrupt while the stack pointer has > wrapped around into the PSP+code. I didn't like that one, either :( > I.e. the original 24-byte was elegant, while the 20-byte version was ugly, But an interesting kind of ugly, wouldn't you say? I still like the IN AL, 60h .. DAS .. JC/JNC idea. It doesn't work with all keypresses but Esc is one of the keys it does work with. -Peter
From: ChrisQuayle on 9 Jan 2007 11:09 Erik Trulsson wrote: > If the system wants to actually *handle* the exception properly then it will > need to know the format of the stack frame in order to find out things like > *which* instruction caused the exception, or which memory access caused a page > fault. > ....and if Apple had designed a machine using 68060, no doubt the install program would have probed for cpu type and loaded the appropriate modules, or patched the os on the fly. To criticise an architectural change because some third party add-on company found it difficult to integrate their product is hardly relevant. It's precisely the sort of problem one would expect to have to solve if you build such products. > The problem was that the stack frame format *changed*. That meant that > you had to get an updated (or at least patched) OS in order to run on > the new CPUs. This was not just a problem for the Mac, but for all other > systems that used th 68k series as well. Well, nothing stays the same if we are to have progress and it's true of many architectures. Peter's incremental approach in action :-)... Chris
From: kenney on 9 Jan 2007 11:15 In article <Pine.LNX.4.61.0701080542300.30635(a)ask.diku.dk>, firefly(a)diku.dk ( Lund) wrote: > Sure, something rudimentary like that, fine, yes, > that's useful. The Z80 had a NMI and three modes of interrupts with Mode 2 and Mode 1 being vectored. If multiple interrupts were possible at the same time they had to have priority settled by external hardware. Ken Young
From: kenney on 9 Jan 2007 11:15
In article <Y4Aoh.13453$696.2319(a)newsfe7-win.ntli.net>, nospam(a)devnul.co.uk (ChrisQuayle) wrote: > Ok, your turn - describe a hardware prioritised > interrupt structure. to fill in the second method... The Z-80 specific peripheral chips had built in support for daisy chaining, or with mode 1 and 2 interrupts you could use external logic to decide which external chip was allowed to place the vector data on the data bus. I happen to have a Z80 book to hand. Ken Young |