Re: [M100] new project

[Mike Stein]

No soldering (or Vnicad) required; turns out that the M100 EXTRAM does indeed 
only use /WR and RAMRST with the XR4 also using /Y0 for the bank selection, all 
plugged into the bus. The 102 connected to an adjacent RAM chip instead, but no 
idea how they connected /Y0 on the 102.

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Wednesday, October 25, 2017 10:39 PM
  Subject: Re: [M100] new project




  On Wed, Oct 25, 2017 at 6:10 PM Mike Stein  wrote:



I think EXTRAM (and presumably also XR4) used RAMRST, at least in the M100; 
where is this Vnicad you speak of? If you mean Vb, I don't think it's available 
on the bus?



  If it was he wouldn’t need a wire soldered to get it :-)


  — John. 

Re: [M100] new project

[Brian White]

Sure as hell sounds cool.
​--
bkw

Re: [M100] new project

[John R. Hogerhuis]

On Wed, Oct 25, 2017 at 6:10 PM Mike Stein  wrote:

>
> I think EXTRAM (and presumably also XR4) used RAMRST, at least in the
> M100; where is this Vnicad you speak of? If you mean Vb, I don't think it's
> available on the bus?
>
>

If it was he wouldn’t need a wire soldered to get it :-)

— John.

Re: [M100] new project

[Mike Stein]

Hey, hey; an expanded XR4 for CP/M was my idea! ;-)

Yeah, it was great to finally meet Phil in person; really sorry that meeting up 
with you couldn't work out.

I think EXTRAM (and presumably also XR4) used RAMRST, at least in the M100; 
where is this Vnicad you speak of? If you mean Vb, I don't think it's available 
on the bus?

As I discussed with Phil I was actually working on an EXTRAM clone (although 
not specifically for CP/M) and exploring how XR4 did its bank switching; do you 
have any specifics?

m
  - Original Message - 
  From: Stephen Adolph 
  To: Model 100 Discussion 
  Sent: Wednesday, October 25, 2017 5:40 PM
  Subject: [M100] new project


  I met up with Phil Avery recently in person, which was a real hoot.  In the 
process I got a front row demo of a T102 running CPM.  Very cool!  Now, this 
T102 was special as it was equipped with a Remem - which provides very flexible 
flash/ram storage.  Specifically, 4MB of flash and 2MB of SRAM.


  What's important here, is that that big pile of SRAM makes for 2 very fast 
RAM disks for CPM.


  Phil and I discussed the challenge of how to make CPM more obtainable.   
Remem was cool, but never easy to install and awful to build.  Keeping the 
serial port free is also nice as it allows for the link to the outside world.


  So, where we landed was that an all-SRAM REX could make CPM more achievable, 
as it would provide not only ram in the critical -7FFF memory space, but 
also supply ramdisk via bank switching in/out of the optrom bank.


  Large SRAM chips (meaning 1MB or bigger) tend to be 3.3V IE they need to be 
buffered to use them in M100-land.


  Anyhow, long story short, I am awaiting 3 "REXCPM" board now, which look a 
lot like REX except with a 2MB SRAM chip, extra buffer chips, and 3 wires that 
need hookup to the M100.  Kinda like (exactly like) a mega-EXTRAM.  


  Back in the day, there was a product called EXTRAM that put RAM in the optrom 
socket - 32kB.  Then there was XR4, which was EXTRAM x 4 or 128kB in the optrom 
socket.  XR4 used the IO/M signal to allow PORT based bank selection.  Here, 
REX is instead listening for an unlock sequence on the address bus to enable 
bank selection.



  I think EXTRAM used 2 wires - Vnicad, /WR

  I think XR4 used 3 wires - Vnicad, IO/M and /WR.

  REXCPM plan is to use 3 wires - Vnicad, /WR and RAMRST.  


  RAMRST may or may not be needed.  That signal is intended to protect memory 
during power down.  Perhaps the developer of XR4 found an alternative way to 
protect the memory.  Anyhow if I can eliminate RAMRST I will.  Anyone have any 
thoughts on the subject?


  In practice this would install the same way as REX2-

  In M100 - 3 wires over to the system bus socket

  in T102 - 3 wires over to an adjacent RAM chip

  in NEC - 3 wires over to a memory module.



  Losing power would wipe the card..so that's a big difference from REX.


  Having said that, SRAM does have advantages, and in principle one could have 
many of the same REX features working on REXCPM - memory backup, option roms 
etc.


  anyhow, that's the update.


  Steve

Re: [M100] new project

[Stephen Adolph]

I looked a bit at a supercap but...we have a battery...we just need a wire!.

What would one need an rtc For?

On Wednesday, October 25, 2017, Brian Brindle  wrote:

> Any thoughts of a battery backup and or a RTC?
>
> On Oct 25, 2017 6:49 PM, "Josh Malone"  > wrote:
>
>> Wow. This sounds very cool! I've never actually run CP/M, and I'm not
>> sure that running it on Model-T is super exciting (probably just because I
>> haven't tried it) but the capabilities of the REXCPM sound awesome.
>>
>> I'm fine with a 3-wire install. Hell, any number of wires to the mobo
>> would not be a turn-off for me using it; basically as long as trace-cutting
>> isn't involved it won't bother me.
>>
>> I'm assuming the CPLD and SRAM are on the other side? Man, that board is
>> gonna be crammed! :)
>>
>> -Josh
>>
>

Re: [M100] new project

[Brian Brindle]

Any thoughts of a battery backup and or a RTC?

On Oct 25, 2017 6:49 PM, "Josh Malone"  wrote:

> Wow. This sounds very cool! I've never actually run CP/M, and I'm not sure
> that running it on Model-T is super exciting (probably just because I
> haven't tried it) but the capabilities of the REXCPM sound awesome.
>
> I'm fine with a 3-wire install. Hell, any number of wires to the mobo
> would not be a turn-off for me using it; basically as long as trace-cutting
> isn't involved it won't bother me.
>
> I'm assuming the CPLD and SRAM are on the other side? Man, that board is
> gonna be crammed! :)
>
> -Josh
>

Re: [M100] new project

[Josh Malone]

Wow. This sounds very cool! I've never actually run CP/M, and I'm not sure
that running it on Model-T is super exciting (probably just because I
haven't tried it) but the capabilities of the REXCPM sound awesome.

I'm fine with a 3-wire install. Hell, any number of wires to the mobo would
not be a turn-off for me using it; basically as long as trace-cutting isn't
involved it won't bother me.

I'm assuming the CPLD and SRAM are on the other side? Man, that board is
gonna be crammed! :)

-Josh

Re: [M100] ROM call: MAKFIL (2239h) help plz

[John Gardner]

Thanks.

On 10/25/17, John R. Hogerhuis  wrote:
> On Wed, Oct 25, 2017 at 2:48 PM, John Gardner  wrote:
>
>> Thanks,  John.  Any particular file you have in mind?  I don't see
>>
>>
> I guess "technical reference" and "technical notes" are the relevant stuff.
>
> -- John.
>

Re: [M100] ROM call: MAKFIL (2239h) help plz

[John R. Hogerhuis]

On Wed, Oct 25, 2017 at 2:48 PM, John Gardner  wrote:

> Thanks,  John.  Any particular file you have in mind?  I don't see
>
>
I guess "technical reference" and "technical notes" are the relevant stuff.

-- John.

Re: [M100] ROM call: MAKFIL (2239h) help plz

[John Gardner]

AOBTW,  that site went about 15 years without an update - Looks different

now,  so I'm guessing the Band is taking the year off...

On 10/25/17, John Gardner  wrote:
> Thanks,  John.  Any particular file you have in mind?  I don't see
>
> a "NEC Programmers Reference".
>
>
>
> On 10/25/17, John R. Hogerhuis  wrote:
>> On Wed, Oct 25, 2017 at 2:17 PM, John Gardner  wrote:
>>
>>> "NEC Programmers  Reference"?
>>>
>>> OK - I'll bite...
>>>
>>>
>> http://www.web8201.net/default.asp?content=tech.asp
>>
>> -- John.
>>
>

Re: [M100] ROM call: MAKFIL (2239h) help plz

[John Gardner]

Thanks,  John.  Any particular file you have in mind?  I don't see

a "NEC Programmers Reference".



On 10/25/17, John R. Hogerhuis  wrote:
> On Wed, Oct 25, 2017 at 2:17 PM, John Gardner  wrote:
>
>> "NEC Programmers  Reference"?
>>
>> OK - I'll bite...
>>
>>
> http://www.web8201.net/default.asp?content=tech.asp
>
> -- John.
>

[M100] new project

[Stephen Adolph]

I met up with Phil Avery recently in person, which was a real hoot.  In the
process I got a front row demo of a T102 running CPM.  Very cool!  Now,
this T102 was special as it was equipped with a Remem - which provides very
flexible flash/ram storage.  Specifically, 4MB of flash and 2MB of SRAM.

What's important here, is that that big pile of SRAM makes for 2 very fast
RAM disks for CPM.

Phil and I discussed the challenge of how to make CPM more obtainable.
Remem was cool, but never easy to install and awful to build.  Keeping the
serial port free is also nice as it allows for the link to the outside
world.

So, where we landed was that an all-SRAM REX could make CPM more
achievable, as it would provide not only ram in the critical -7FFF
memory space, but also supply ramdisk via bank switching in/out of the
optrom bank.

Large SRAM chips (meaning 1MB or bigger) tend to be 3.3V IE they need to be
buffered to use them in M100-land.

Anyhow, long story short, I am awaiting 3 "REXCPM" board now, which look a
lot like REX except with a 2MB SRAM chip, extra buffer chips, and 3 wires
that need hookup to the M100.  Kinda like (exactly like) a mega-EXTRAM.

Back in the day, there was a product called EXTRAM that put RAM in the
optrom socket - 32kB.  Then there was XR4, which was EXTRAM x 4 or 128kB in
the optrom socket.  XR4 used the IO/M signal to allow PORT based bank
selection.  Here, REX is instead listening for an unlock sequence on the
address bus to enable bank selection.

I think EXTRAM used 2 wires - Vnicad, /WR
I think XR4 used 3 wires - Vnicad, IO/M and /WR.
REXCPM plan is to use 3 wires - Vnicad, /WR and RAMRST.

RAMRST may or may not be needed.  That signal is intended to protect memory
during power down.  Perhaps the developer of XR4 found an alternative way
to protect the memory.  Anyhow if I can eliminate RAMRST I will.  Anyone
have any thoughts on the subject?

In practice this would install the same way as REX2-
In M100 - 3 wires over to the system bus socket
in T102 - 3 wires over to an adjacent RAM chip
in NEC - 3 wires over to a memory module.

Losing power would wipe the card..so that's a big difference from REX.

Having said that, SRAM does have advantages, and in principle one could
have many of the same REX features working on REXCPM - memory backup,
option roms etc.

anyhow, that's the update.

Steve


[image: Inline image 1]

Re: [M100] ROM call: MAKFIL (2239h) help plz

[John R. Hogerhuis]

On Wed, Oct 25, 2017 at 2:17 PM, John Gardner  wrote:

> "NEC Programmers  Reference"?
>
> OK - I'll bite...
>
>
http://www.web8201.net/default.asp?content=tech.asp

-- John.

Re: [M100] ROM call: MAKFIL (2239h) help plz

[John Gardner]

"NEC Programmers  Reference"?

OK - I'll bite...



On 10/25/17, Stephen Adolph  wrote:
> Boy I wish we could all agree on variable names in M100!
>
> here is my assessment of what you've done-
>
> 1)  you are using the wrong starting location.  Think you need to use the
> ASCTAB (DOSTART?) location which is the lowest first byte of .DO file data.
> 2)  you need to ensure your new directory entry gets the correct
> (incorrect) address , meaning you need to trick LNKFIL (DIROK?) to order
> the file names correctly.  in this case ASCTAB-1. in this way the current
> directory entry, that points to ASCTAB, will be ordered and linked
> correctly.
>
> make sense?
> and I agree with John, without the NEC reference I would never have gotten
> REX to work.
>
>
> On Wed, Oct 25, 2017 at 4:59 PM, Stephen Adolph 
> wrote:
>
>>
>>
>> Here is some code to look at.
>> do you run LNKFIL afterwards? you must!
>>
>> note you must ensure the address of the new file name in the ram
>> directory
>> is 1 less than the actual starting location to ensure LNKFIL orders the
>> file names correctly.
>>
>>
>>
>> ramfile_copy_DO:; new directory entry address in TEMP3
>> ; source directory entry at input buffer
>>
>> ; ASCTAB-1 start of new file in directory entry
>> ; make xx byte hole at ASCTAB, xx is file length incl
>> EOF
>> ; copy data to hole
>> ; LNKFIL
>>
>> lhldBINTAB; hl points to injection point
>> shldTEMP3; store injection point in TEMP3
>> dcxh
>> shldTEMP1; start address for new directory entry in
>> TEMP1
>>
>> callramcopy_makehole; make the hole
>> callramfile_copy_file; copy the data into the hole
>> jmprammenu_loop0; done
>>
>> ;---
>> 
>> ramcopy_makehole:
>>
>> lhld TEMP4; get length of file
>> pushh; on stack
>>
>>   
>>
>> popb; length of file in bc
>>
>> lhldTEMP3; hl is injection point
>>
>> rst6
>> .dwMAKHOL; make hole BC long at HL, adjusting
>> pointers
>>
>> ; MAKHOL adjusts BINTAB, VARTAB, ARYTAB
>> ; MAKHOL does not adjust ASCTAB, needed by LNKFIL
>>
>>
>> jcramfile_copy_fail4; jump here if not enough space
>>
>> ret
>>
>>
>> ;---
>> 
>> ramfile_copy_file:; copy the data into the hole
>>
>> ; TEMP2 new directory entry address
>> ; INPUT_BUFFER source directory entry, points to
>> source file
>> ; TEMP3 injection point of new file
>> ; TEMP1 start address for directory entry
>> ; TEMP4 size
>> ; TEMP5 source data (system file)
>>
>> lhldTEMP4
>> movb,h
>> movc,l; get size in BC
>>
>> lhldTEMP3; target in hl
>> xchg; target in de
>>
>> ldaDSTATE
>> ani1000b
>> jzramfile_copy_file_1
>> ; use when in ram file mode
>> lhldINPUT_BUFFER+1d
>> callfix_hl_mode; correct hl for lower block
>>
>> ; hl source, de target
>> callramfile_copy_block; copy block
>> jmpramfile_copy_file_2
>>
>> ramfile_copy_file_1:; use when copying system files
>> lhldTEMP5; hl = source
>> ; hl source, de target
>> xchg; de source hl target
>> callMOVEB_D_H; mov bc bytes from de to hl
>>
>> ramfile_copy_file_2:
>>
>> lhldTEMP2; TEMP2 holds pointer for new directory
>> entry
>> inxh
>> xchg
>> lhldTEMP1; start address for directory entry in hl
>> shlx; store new start of file into new directory
>> entry
>>
>> rst6
>> .dwLNKFIL; fix up directory
>>
>>
>> ret
>>
>>
>> On Wed, Oct 25, 2017 at 4:40 PM, Stephen Adolph 
>> wrote:
>>
>>> willard, would commented assembly help?
>>> I have this working in REX Manager...
>>>
>>>
>>> On Wed, Oct 25, 2017 at 4:20 PM, Willard Goosey  wrote:
>>>
 So, there is this (from Mike Nugent's RAM-ROM file)

 ;2239H - Insert entry into directory.
 ; Entry:
 ;   HL - Points to empty directory slot
 ;   DE - Contains address of file in RAM
 ;A - Attribute (80h=.BA, C0h=.DO, A0h=.CO, etc.)
 ; Note: Routine gets filename from FC93H, where it must be
 ;   stored,padded with spaces, no delimiter.
 ; Exit: DE - Unchanged

 And I have the 

Re: [M100] ROM call: MAKFIL (2239h) help plz

[Stephen Adolph]

Boy I wish we could all agree on variable names in M100!

here is my assessment of what you've done-

1)  you are using the wrong starting location.  Think you need to use the
ASCTAB (DOSTART?) location which is the lowest first byte of .DO file data.
2)  you need to ensure your new directory entry gets the correct
(incorrect) address , meaning you need to trick LNKFIL (DIROK?) to order
the file names correctly.  in this case ASCTAB-1. in this way the current
directory entry, that points to ASCTAB, will be ordered and linked
correctly.

make sense?
and I agree with John, without the NEC reference I would never have gotten
REX to work.


On Wed, Oct 25, 2017 at 4:59 PM, Stephen Adolph 
wrote:

>
>
> Here is some code to look at.
> do you run LNKFIL afterwards? you must!
>
> note you must ensure the address of the new file name in the ram directory
> is 1 less than the actual starting location to ensure LNKFIL orders the
> file names correctly.
>
>
>
> ramfile_copy_DO:; new directory entry address in TEMP3
> ; source directory entry at input buffer
>
> ; ASCTAB-1 start of new file in directory entry
> ; make xx byte hole at ASCTAB, xx is file length incl
> EOF
> ; copy data to hole
> ; LNKFIL
>
> lhldBINTAB; hl points to injection point
> shldTEMP3; store injection point in TEMP3
> dcxh
> shldTEMP1; start address for new directory entry in
> TEMP1
>
> callramcopy_makehole; make the hole
> callramfile_copy_file; copy the data into the hole
> jmprammenu_loop0; done
>
> ;---
> 
> ramcopy_makehole:
>
> lhld TEMP4; get length of file
> pushh; on stack
>
>   
>
> popb; length of file in bc
>
> lhldTEMP3; hl is injection point
>
> rst6
> .dwMAKHOL; make hole BC long at HL, adjusting pointers
>
> ; MAKHOL adjusts BINTAB, VARTAB, ARYTAB
> ; MAKHOL does not adjust ASCTAB, needed by LNKFIL
>
>
> jcramfile_copy_fail4; jump here if not enough space
>
> ret
>
>
> ;---
> 
> ramfile_copy_file:; copy the data into the hole
>
> ; TEMP2 new directory entry address
> ; INPUT_BUFFER source directory entry, points to
> source file
> ; TEMP3 injection point of new file
> ; TEMP1 start address for directory entry
> ; TEMP4 size
> ; TEMP5 source data (system file)
>
> lhldTEMP4
> movb,h
> movc,l; get size in BC
>
> lhldTEMP3; target in hl
> xchg; target in de
>
> ldaDSTATE
> ani1000b
> jzramfile_copy_file_1
> ; use when in ram file mode
> lhldINPUT_BUFFER+1d
> callfix_hl_mode; correct hl for lower block
>
> ; hl source, de target
> callramfile_copy_block; copy block
> jmpramfile_copy_file_2
>
> ramfile_copy_file_1:; use when copying system files
> lhldTEMP5; hl = source
> ; hl source, de target
> xchg; de source hl target
> callMOVEB_D_H; mov bc bytes from de to hl
>
> ramfile_copy_file_2:
>
> lhldTEMP2; TEMP2 holds pointer for new directory entry
> inxh
> xchg
> lhldTEMP1; start address for directory entry in hl
> shlx; store new start of file into new directory entry
>
> rst6
> .dwLNKFIL; fix up directory
>
>
> ret
>
>
> On Wed, Oct 25, 2017 at 4:40 PM, Stephen Adolph 
> wrote:
>
>> willard, would commented assembly help?
>> I have this working in REX Manager...
>>
>>
>> On Wed, Oct 25, 2017 at 4:20 PM, Willard Goosey  wrote:
>>
>>> So, there is this (from Mike Nugent's RAM-ROM file)
>>>
>>> ;2239H - Insert entry into directory.
>>> ; Entry:
>>> ;   HL - Points to empty directory slot
>>> ;   DE - Contains address of file in RAM
>>> ;A - Attribute (80h=.BA, C0h=.DO, A0h=.CO, etc.)
>>> ; Note: Routine gets filename from FC93H, where it must be
>>> ;   stored,padded with spaces, no delimiter.
>>> ; Exit: DE - Unchanged
>>>
>>> And I have the ROM call itself working in smallclib... but this is only
>>> part of the story. To use this successfully (ie without causing a cold
>>> start) we need to know more about it.
>>>
>>> I've been trying to create a .DO file.
>>>
>>> 1) Where do yo get a starting address for the file? I've 

Re: [M100] ROM call: MAKFIL (2239h) help plz

[Stephen Adolph]

Here is some code to look at.
do you run LNKFIL afterwards? you must!

note you must ensure the address of the new file name in the ram directory
is 1 less than the actual starting location to ensure LNKFIL orders the
file names correctly.



ramfile_copy_DO:; new directory entry address in TEMP3
; source directory entry at input buffer

; ASCTAB-1 start of new file in directory entry
; make xx byte hole at ASCTAB, xx is file length incl
EOF
; copy data to hole
; LNKFIL

lhldBINTAB; hl points to injection point
shldTEMP3; store injection point in TEMP3
dcxh
shldTEMP1; start address for new directory entry in
TEMP1

callramcopy_makehole; make the hole
callramfile_copy_file; copy the data into the hole
jmprammenu_loop0; done

;---
ramcopy_makehole:

lhld TEMP4; get length of file
pushh; on stack

  

popb; length of file in bc

lhldTEMP3; hl is injection point

rst6
.dwMAKHOL; make hole BC long at HL, adjusting pointers

; MAKHOL adjusts BINTAB, VARTAB, ARYTAB
; MAKHOL does not adjust ASCTAB, needed by LNKFIL


jcramfile_copy_fail4; jump here if not enough space

ret


;---
ramfile_copy_file:; copy the data into the hole

; TEMP2 new directory entry address
; INPUT_BUFFER source directory entry, points to source
file
; TEMP3 injection point of new file
; TEMP1 start address for directory entry
; TEMP4 size
; TEMP5 source data (system file)

lhldTEMP4
movb,h
movc,l; get size in BC

lhldTEMP3; target in hl
xchg; target in de

ldaDSTATE
ani1000b
jzramfile_copy_file_1
; use when in ram file mode
lhldINPUT_BUFFER+1d
callfix_hl_mode; correct hl for lower block

; hl source, de target
callramfile_copy_block; copy block
jmpramfile_copy_file_2

ramfile_copy_file_1:; use when copying system files
lhldTEMP5; hl = source
; hl source, de target
xchg; de source hl target
callMOVEB_D_H; mov bc bytes from de to hl

ramfile_copy_file_2:

lhldTEMP2; TEMP2 holds pointer for new directory entry
inxh
xchg
lhldTEMP1; start address for directory entry in hl
shlx; store new start of file into new directory entry

rst6
.dwLNKFIL; fix up directory


ret


On Wed, Oct 25, 2017 at 4:40 PM, Stephen Adolph 
wrote:

> willard, would commented assembly help?
> I have this working in REX Manager...
>
>
> On Wed, Oct 25, 2017 at 4:20 PM, Willard Goosey  wrote:
>
>> So, there is this (from Mike Nugent's RAM-ROM file)
>>
>> ;2239H - Insert entry into directory.
>> ; Entry:
>> ;   HL - Points to empty directory slot
>> ;   DE - Contains address of file in RAM
>> ;A - Attribute (80h=.BA, C0h=.DO, A0h=.CO, etc.)
>> ; Note: Routine gets filename from FC93H, where it must be
>> ;   stored,padded with spaces, no delimiter.
>> ; Exit: DE - Unchanged
>>
>> And I have the ROM call itself working in smallclib... but this is only
>> part of the story. To use this successfully (ie without causing a cold
>> start) we need to know more about it.
>>
>> I've been trying to create a .DO file.
>>
>> 1) Where do yo get a starting address for the file? I've tried every
>> variant of COSTART (FBB0h) and DOSTART (FBAEh). At best I can get is
>> intact DO files and the CO file directory entries switched around (using
>> COSTART-1). DOSTART results in the text files being switched around and
>> the binary files remaining correct. Anything else (COSTART or
>> DOSTART-1) leads to file corruption and/or cold starts.
>>
>> 2)Is there a second directory-repair routine, besides DIROK (2146h)?
>> Because DIROK() is not being sufficient. :-(
>>
>> Here is the test code. DO NOT USE
>> /*tmf.c
>>  *Test MakFil
>>  *test for Model 100 Small C-85 Library
>>  *
>>  *Willard Goosey
>>  *goo...@sdc.org
>>  *10/19/2017
>>  */
>>
>> #include "m100vars.h"
>> #include "dir.h"
>>
>> /*MAKFIL extension bytes: */
>> #define BA 0x80
>> #define DO 0xC0
>> #define CO 0xA0
>>
>> main(char A, char *HL)
>> {
>>   char *name;
>>   struct dir *slot;
>>   char *start;
>>   int i;
>>
>>   name= 

Re: [M100] ROM call: MAKFIL (2239h) help plz

[John R. Hogerhuis]

I might have mentioned it before but the best reference on file management
is the NEC programmers reference. Lots of sample code and unintentionally
humorous English explication.

— John.

Re: [M100] ROM call: MAKFIL (2239h) help plz

[Stephen Adolph]

willard, would commented assembly help?
I have this working in REX Manager...


On Wed, Oct 25, 2017 at 4:20 PM, Willard Goosey  wrote:

> So, there is this (from Mike Nugent's RAM-ROM file)
>
> ;2239H - Insert entry into directory.
> ; Entry:
> ;   HL - Points to empty directory slot
> ;   DE - Contains address of file in RAM
> ;A - Attribute (80h=.BA, C0h=.DO, A0h=.CO, etc.)
> ; Note: Routine gets filename from FC93H, where it must be
> ;   stored,padded with spaces, no delimiter.
> ; Exit: DE - Unchanged
>
> And I have the ROM call itself working in smallclib... but this is only
> part of the story. To use this successfully (ie without causing a cold
> start) we need to know more about it.
>
> I've been trying to create a .DO file.
>
> 1) Where do yo get a starting address for the file? I've tried every
> variant of COSTART (FBB0h) and DOSTART (FBAEh). At best I can get is
> intact DO files and the CO file directory entries switched around (using
> COSTART-1). DOSTART results in the text files being switched around and
> the binary files remaining correct. Anything else (COSTART or
> DOSTART-1) leads to file corruption and/or cold starts.
>
> 2)Is there a second directory-repair routine, besides DIROK (2146h)?
> Because DIROK() is not being sufficient. :-(
>
> Here is the test code. DO NOT USE
> /*tmf.c
>  *Test MakFil
>  *test for Model 100 Small C-85 Library
>  *
>  *Willard Goosey
>  *goo...@sdc.org
>  *10/19/2017
>  */
>
> #include "m100vars.h"
> #include "dir.h"
>
> /*MAKFIL extension bytes: */
> #define BA 0x80
> #define DO 0xC0
> #define CO 0xA0
>
> main(char A, char *HL)
> {
>   char *name;
>   struct dir *slot;
>   char *start;
>   int i;
>
>   name= "RTMF1.DO";
>   start= COSTART-1; //start at beginning of CO files
>
>   slot=FREDIR();
>
>   hex16(start);CRLF();
>
>   prsnam(name,strlen(name));
>
>   hex16(makfil(slot,start,DO)); CRLF();
>   if(makhol(1,start)<0)
>   {
> BEEP();
> MENU();
>   }
>   *start=0x1a;
>  //makfil doesn't autoinsert EOF
>   DIROK();
> }
>
> HELP
> Willard
> --
> Willard Goosey  goo...@sdc.org
> Socorro, New Mexico, USA
> I search my heart and find Cimmeria, land of Darkness and the Night.
>   -- R.E. Howard
>

[M100] ROM call: MAKFIL (2239h) help plz

[Willard Goosey]

So, there is this (from Mike Nugent's RAM-ROM file)

;2239H - Insert entry into directory.
; Entry:
;   HL - Points to empty directory slot
;   DE - Contains address of file in RAM
;A - Attribute (80h=.BA, C0h=.DO, A0h=.CO, etc.)
; Note: Routine gets filename from FC93H, where it must be
;   stored,padded with spaces, no delimiter.
; Exit: DE - Unchanged

And I have the ROM call itself working in smallclib... but this is only
part of the story. To use this successfully (ie without causing a cold
start) we need to know more about it.

I've been trying to create a .DO file.

1) Where do yo get a starting address for the file? I've tried every
variant of COSTART (FBB0h) and DOSTART (FBAEh). At best I can get is
intact DO files and the CO file directory entries switched around (using
COSTART-1). DOSTART results in the text files being switched around and
the binary files remaining correct. Anything else (COSTART or
DOSTART-1) leads to file corruption and/or cold starts.

2)Is there a second directory-repair routine, besides DIROK (2146h)?
Because DIROK() is not being sufficient. :-(

Here is the test code. DO NOT USE
/*tmf.c
 *Test MakFil
 *test for Model 100 Small C-85 Library
 *
 *Willard Goosey
 *goo...@sdc.org
 *10/19/2017
 */

#include "m100vars.h"
#include "dir.h"

/*MAKFIL extension bytes: */
#define BA 0x80
#define DO 0xC0
#define CO 0xA0

main(char A, char *HL)
{
  char *name; 
  struct dir *slot;
  char *start;
  int i;

  name= "RTMF1.DO";
  start= COSTART-1; //start at beginning of CO files

  slot=FREDIR();  

  hex16(start);CRLF();

  prsnam(name,strlen(name));

  hex16(makfil(slot,start,DO)); CRLF();
  if(makhol(1,start)<0)
  {
BEEP();
MENU();
  }
  *start=0x1a;
 //makfil doesn't autoinsert EOF
  DIROK();
}

HELP
Willard
-- 
Willard Goosey  goo...@sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard