"CP/M compatible" vs. "MS-DOS Compatible" machines?

[Allison]

>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
>   From: "Dave Dunfield" <dave06a at dunfield.com>
>   Date: Mon, 04 Feb 2008 07:21:16 -0500
>     To: "General Discussion: On-Topic and Off-Topic Posts"	<cctalk at classiccmp.org>
>
>> >I'd like to implement something that'd not only use one of those single-byte 
>> >calls,  but take the data inline,  as well -- no need to load it into 
>> >registers to pass it along,  though there are some rather clumsy aspects to 
>> >getting the stack pointer and fixing it...
>> 
>> That was easy in 8080.
>> 
>> ;routine gets 16bit word passed on stack before call
>> ; doesn't do anthing but put that item in bc
>> RRST:     org   010h
>>           shld  hlsave
>>           pop   hl      ;hl has return address
>>           pop   bc      ; BC has data
>>           push  hl      ; hl back to stack
>>           lhld  hlsave  ; restor hl
>>           ret   
>> 
>> ;caller
>> caller:    push bc   ;data in bc
>>            rst2
>>            ......
>
>I don't think he was talking about pushing data on the stack,
>I thought he was refering to putting the system service request
>number inline with the code.

The way you can "force that" in cpm is use the above code to call 
say RST2 where the call is broken out and organized in registers
per cpm normal.  It also has to preserve registers and adjust the 
returned data to be on the stack but it's not that bad.

>This is exactly what I do on both my DMF (8080) and CUBIX (6809)
>OS's.

Understood and like it better too. However it's more natural for 
6809 where 8080/z80 is kinda clunky around playing with stack.

>I use an 'SSR' macro which looks something like (DMF/8080):
>
>SSR	MACRO
>	RST	2
>	DB	\1
>	END
>
>
>It's fairly easy to fetch this:
>
>SSRENT:	STA		savea		; Save accumulator
>		XTHL				; HL = calling address
>		MOV		A,M			; Get service request number
>		INX		H			; Skip for return
>		XTHL				; Restore HL & new return address
>; Now you have the SSR number in A
>; most likely you would use it to index into a handler
>; table sith something like: (untested)
>		PUSH	H			; Save application HL
>		MOV		L,A			; L = SSR number
>		MVI		H,0			; Zero high
>		DAD		H			; x2 for two byte entries
>		PUSH	B			; Save BC
>		LXI		B,JMPTAB	; Point to jump table
>		DAD		B			; Offset to table
>		POP		B			; Restore B
>		MOV		A,M			; Get low address
>		INX		H			; Advance to high
>		MOV		H,M			; Get high address
>		MOV		L,A			; Set low address
>		XTHL				; Restore HL, dest on stack
>		LDA		savea		; Restore A
>		RET					; Jump to caller

That mkes the code read easier and may be easier to maintain but
that hides whats really there unles you unroll the code.

>		
>'JMPTAB' would contain a series of 2-byte addresses of
>the individual SSR handlers.
>
>In practice it's usually a bit more complex ... iirc
>in my SSR entry I save most of the registers (so that
>the handlers don't have to) and switch to my own stack
>(but it's been a very long time so I may be mistaken).
>
>In the application code, you can then do things like:
>
>		MVI		A,'?'		; Get prompt
>		SSR		3			; Output to console (two byte OS call)
>
>
>Dave

Those are interesting ways to deal with it that I'd not have done.
Chalk that up to lack of imagination on my part.

Allison




>--
>dave06a (at)    Dave Dunfield
>dunfield (dot)  Firmware development services & tools: www.dunfield.com
>com             Collector of vintage computing equipment:
>                http://www.classiccmp.org/dunfield/index.html