6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Nov 12, 2024 11:00 am

All times are UTC




Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Fri Jan 13, 2017 1:14 pm 
Offline
User avatar

Joined: Wed Aug 17, 2005 12:07 am
Posts: 1250
Location: Soddy-Daisy, TN USA
The experience with the members of this forum really amaze me. I was a child of the 70's and didn't get my first computer until 81-82 (TI-99 4/a). Shortly after that, I got a C64C and spent most of the 80's programming 6502 (6510) assembly on it. When I was 12, I *invented* a way for the C64 to display hundreds of colors by rapidly flicking two colors at 60FPS.

Of course, I wasn't the first to invent that but in my 12 year old mind...in a small country town....I was king of the computers. :-D

Now, I spent several hours yesterday working with Vaadin and Spring. Certainly a letdown compared to those days of the C64.

_________________
Cat; the other white meat.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 13, 2017 1:20 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
Thanks for the details!


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 13, 2017 7:02 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
I don't know the mechanism, but CP/M certainly had a way to report how much free memory there was, since it's minimum requirement was 20K of RAM, programs must have had a way of ascertaining, portably, how big the TPA was.

CP/M 3.0 later had a mechanism to add resident modules below the BDOS, so those would consume memory. Also, ZCPR3 had different buffers you could optionally allocate. ZCPR3 was CP/M compatible. All these suggest that there was a portable mechanism to find how large the free space was.

MS-DOS COM files are a direct descendant of CP/M COM files, essentially static binary files designed to be loaded and started at $0100. You could almost mechanically port CP/M code to MS-DOS using the Tiny memory model (CS=DS=SS), since the 8088 and 8080 were so similar (I don't think they shared op codes, but they might have).


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 13, 2017 7:19 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
Ah:
> The address field at BOOT+0006H (normally 006H) contains the value of FBASE and can be used to determine the size of available memory

(From http://www.cpm.z80.de/manuals/archive/cpm22htm/ch5.htm)


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 13, 2017 10:28 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
Yea, ok.

Folks mentioned FLEX, so I took a gander at it. It's interesting to contrast CP/M and FLEX.

Specifically, all calls to BDOS in CP/M go through a single entry point, whereas in FLEX, the calls go to specific addresses.

Now, in CP/M there's simply a JMP at the single entry point, to go wherever the dispatch code is (which, coincidentally appears to be the same as FBASE, and I think the entry point in to CP/M is BASE+0005H, which would make it JMP FBASE, anyway).

But in FLEX, it's clear that all of the entry point address are also simply place to put a JMP in to the actual code.

However the architecture mandate is different. FLEX assumes code at specific locations in higher memory ($CXXX), whereas CP/M requires only some byte in very low memory. JMP 0000H is how a program "exits", and warmstarts CP/M. The CP/M technique also seems a bit more extensible (up to 255 functions using the basic function number, could always have an extended function).

Down side is that CP/M is a bit more expensive: set the register, JSR to a JMP to some dispatch code that inevitably calls the desired routine vs a simple JSR to a JMP. But, easy to argue that these calls are high level enough, and so slow anyway (couple of more instructions are going to save you when you hit that floppy…) that they're not missed.

Now, contrast this to how the Atari did it.

With the Atari, they had a single entry point to the Central IO system. They allowed 8 channels, also at a specified point in memory. They also had a table of device drivers.

So you would select a channel, specify a device name (like K: for keyboard, or D:FILE.TXT for a disk file), "open" the device, then call the common entry point with X set to the channel number. The table of device drivers was extensible, you could add your own, or override a system supplied one.

Whereas CP/M and FLEX had a different routine for writing to disk vs writing to the console, with the Atari you just wrote to the D device instead of the S(screen) device. To format a diskette on the Atari, you made an extended command to the Disk driver. The calls were the same. Much like in Unix, you basically have open, read, write, close, and ioctl that works for "anything". In CP/M you would pass a pointer to a FCB, whereas with the Atari, you passed the channel number to a list of fixed "FCBs" (they don't call them that). Likely they chose to do this because passing pointer is more of a pain than simply passing a register on the 6502.

The Atari had no real need to strive for portability, but it's easy to see if you make the Atari CIO call similar to the way CP/M does it (through a RAM vector), it could be quite portable.


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 11, 2019 9:43 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
GARTHWILSON wrote:

Glenn Holmer gives a very helpful talk, with slides, on the C64 version of GeckOS, at the Vintage Computer Festival MidWest (VCFMW) 2019, at https://www.youtube.com/watch?v=jtlAOdJmeDI . See also Cenbe's commentary on it, at https://www.lyonlabs.org/commodore/onre ... lysis.html .

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 01, 2019 12:12 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
The Commodore KERNAL (first released in 1977 with the PET 2001, but continued and expanded through all their 8-bit systems), generally in a separate ROM from BASIC and certainly logically separate, had a device-independent I/O system where each device had an assigned number from 0-15 (0=keyboard, 1=cassette, 3=display, 8=first floppy drive, etc.). Ther was a standard set of vectors to open channels on a device for read/write, sending commands, etc., read and write those channels, and so on. Things were vectored through jump tables so that one could add further "virtual" devices 32-255.

_________________
Curt J. Sampson - github.com/0cjs


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 01, 2019 2:49 am 
Offline

Joined: Mon Apr 30, 2018 10:12 pm
Posts: 15
floobydust wrote:
BigEd wrote:
(Got to love that custom microcode - thanks for that detail floobydust!)


Yes, microcode was stored on a disk drive in a special location. There was just enough "smarts" built in to go out and load microcode into control storage first, then you had a CPU that actually worked. Every now and then there would be a microcode update, or patch. A set of diskettes would be sent and the CE (IBM's service rep) would apply them by invoking a utility and feeding diskettes to the machine. Considering the timeframe, it was quite an advanced technology. System Boot started with "initial microcode load".


PTF's? Program Temporary Fixes? There was nothing temporary about them! The place I worked at was a VAR, I got to install them on multiple S/36's, D2K if I remember correctly. For a while we had 1255 MICR readers. that cable was huge. The PTF's would fail if the 1255 was not physically disconnected from the S/36 and left disconnected for some period of time.

Fun Times!

Walter


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 01, 2019 5:47 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
walter.preuninger wrote:

PTF's? Program Temporary Fixes? There was nothing temporary about them! The place I worked at was a VAR, I got to install them on multiple S/36's, D2K if I remember correctly. For a while we had 1255 MICR readers. that cable was huge. The PTF's would fail if the 1255 was not physically disconnected from the S/36 and left disconnected for some period of time.

Fun Times!

Walter


Well, IIRC, the 1255 MICR used BUS/TAG cables, which were pretty thick and could be very long lengths, 15 feet and longer connecting it to the control unit. If you want to see really fat cables, the 1403 printer had a pair of "shoe connectors" that huge pin connectors slid into and those cables ran to the control unit. Those cables were pushing 2" in diameter.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: