jchikin@polyslo.UUCP (Chikin Joe) (09/27/87)
Does anyone know if the 1750 REU can be used in conjunction with C-Power 128 as a ramdisk or external drive? I have C-Power and it makes no reference to the 1750 as a possible device. I noticed that someone modified their shell, compiler, and linker to accomodate the 1581 drive. Can the same be done to the C-Power 128? Has anyone done it yet? If not, does anyone have any experience with the shell's programming structure? I'll try to modify it as a last resort but I hope someone has rewritten the shell to be compatible with the 1750. Thanks in advance. Chikin Joe Cal Poly Slo, Computer Science Dept.
dwl10@amdahl.amdahl.com (Dave Lowrey) (09/28/87)
In article <467@polyslo.UUCP> jchikin@polyslo.UUCP (Chikin Joe) writes: >Does anyone know if the 1750 REU can be used in conjunction with >C-Power 128 as a ramdisk or external drive? I have C-Power and it >makes no reference to the 1750 as a possible device. I noticed that >someone modified their shell, compiler, and linker to accomodate the >1581 drive. Can the same be done to the C-Power 128? Has anyone done >it yet? If not, does anyone have any experience with the shell's >programming structure? I'll try to modify it as a last resort but >I hope someone has rewritten the shell to be compatible with the 1750. > There is a very big problem you encounter when trying to modify the C-Power shell (at least on the 64, but I would imagine it to be the same on the 128) is that there is very little memory avaliable to put new code into the shell. C-Power's shell resides in memory from $0801 to $17ff. Programs that run under the shell are loaded starting at $1800. No room to add any code. It wouldn't be too hard to modify the shell to load starting at a higher address, and you can easily modify link.sh to relocate starting at that address. But, you would then have to re-locate cc.sh, compiler, translator, link.sh, and any other utilities that you don't have source for to the new address. That is not easy! Sooooo, adding anything like an REU to the shell is not an easy thing to do. I guess if you wanted to do overlays......... Now, it would be possible to do library routines to allow the programs you write to have access to the REU, but that is another matter. -- ------------------------------------------------------------------- "Familiarity breeds attempt" Dave Lowrey Amdahl Corp. Houston, Texas (713)-850-8828 ...!{ihnp4,cbosgd,hplabs,oliveb}!amdahl!dwl10 [ The opinions expressed <may> be those of the author and not necessarily those of his most eminent employer. ]
rayz@csustan.UUCP (10/01/87)
In article <15298@amdahl.amdahl.com> dwl10@amdahl.amdahl.com (Dave Lowrey) writes: >C-Power's shell resides in memory from $0801 to $17ff. Programs that >run under the shell are loaded starting at $1800. No room to add >any code. I did a disassembly of the C64 shell a year and a half ago. There *is* some room for expansion. The region from $0801 ends somewhere short of $17ff. Then there is some storage which extends up to $17ff. There is room for expansion between the code and storage. Sorry, I don't remember how much right now. It wasn't a lot... Also, there was a lot of code which could be quite trivially shortened and improved. I opened up a *lot* of space for expansion by rewrites of existing code. Of course, you need a good symbolic disassembly to start doing things like that.
dwl10@amdahl.UUCP (10/01/87)
In article <967@csustan.UUCP> rayz@csustan.UUCP (R. L. Zarling) writes: >In article <15298@amdahl.amdahl.com> dwl10@amdahl.amdahl.com (Dave Lowrey) writes: >>C-Power's shell resides in memory from $0801 to $17ff. Programs that >>run under the shell are loaded starting at $1800. No room to add >>any code. > >I did a disassembly of the C64 shell a year and a half ago. There *is* some >room for expansion. The region from $0801 ends somewhere short of $17ff. >Then there is some storage which extends up to $17ff. There is room for >expansion between the code and storage. Sorry, I don't remember how much >right now. It wasn't a lot... > >Also, there was a lot of code which could be quite trivially shortened and >improved. I opened up a *lot* of space for expansion by rewrites of >existing code. Of course, you need a good symbolic disassembly to start >doing things like that. I beg to differ, but there isn't much spare room above the shell code. Brief shell memory map: $0801-$1677 - Shell code $1678-$16c8 - Command input buffer $16c9-$1749 - Buffer used by s/f/printf library routine $174a-$179a - Buffer used by library routines to buffer keyboard input $179b-$17ae - Cmd parm pointers $17ad-$17c7 - File neame for re-directed I/O $17c8-$17db - Name of currently loaded program $17dc-$17e6 - Buffer for disk status message $17e7-$17f6 - I/O status buffers $17f7 - Current offset into kbd buffer $17f8-$17f9 - Number of chars in kbd buffer $17fa - "SYS" device number $17fb - "SYS" drive number $17fc - "WORK" device number $17fd - "WORK" drive number $17fe - stdin file number $17ff - stdout file number $1800-$cfff - User's programs As you can see, not much room to spare. You could indeed re-code some of the existing shell code. Perhaps even eliminate some, such as "rm", "mv", and such (you still have the "disk" command that can do the same thing). There is even a routine, from $14eb-$1506 that doesn't seem to be called by anyone else. So, if you feel up to the challange, go ahead an try to add the RAM-DISK code. But it won't be easy. If you want, you can just lend me your REU for a few weeks, and I will try :-). -- ------------------------------------------------------------------- "Familiarity breeds attempt" Dave Lowrey Amdahl Corp. Houston, Texas (713)-850-8828 ...!{ihnp4,cbosgd,hplabs,oliveb}!amdahl!dwl10 [ The opinions expressed <may> be those of the author and not necessarily those of his most eminent employer. ]
rayz@csustan.UUCP (R. L. Zarling) (10/06/87)
In article <15454@amdahl.amdahl.com> dwl10@amdahl.amdahl.com (Dave Lowrey) writes: >Brief shell memory map: ... > >As you can see, not much room to spare. You could indeed re-code some of >the existing shell code. Perhaps even eliminate some, such as "rm", "mv", >and such (you still have the "disk" command that can do the same thing). > >There is even a routine, from $14eb-$1506 that doesn't seem to be called >by anyone else. Your map is for the latest shell, and does not correspond directly to mine (v2.6). In addition to combining the rm, mv, etc buffers which were internal to the code, I found a large 128 byte buffer at 16d4 in which only the first 20 bytes were ever used (for conversion of numbers to character strings mostly). From your map, it looks like that code may have been rewritten in the newer shell, or perhaps one of your buffers at 16c9 or 174a doesn't need to be as big as it is. Or, maybe the latest shell doesn't have any extra space at the end. As far as I could tell, the only *functional* change in the shell going to the newer version was the addition of an extra routine in the jump table. But, as you said, there was plenty of room for internal improve- ments. --ray
star@inuxb.UUCP (Byron Johnson) (10/13/87)
> In article <15454@amdahl.amdahl.com> dwl10@amdahl.amdahl.com (Dave Lowrey) writes: > >Brief shell memory map: > ... > > > >As you can see, not much room to spare. You could indeed re-code some of > >the existing shell code. Perhaps even eliminate some, such as "rm", "mv", > >and such (you still have the "disk" command that can do the same thing). > > > >There is even a routine, from $14eb-$1506 that doesn't seem to be called > >by anyone else. > > Your map is for the latest shell, and does not correspond directly to > mine (v2.6). In addition to combining the rm, mv, etc buffers which were > internal to the code, I found a large 128 byte buffer at 16d4 in which only > the first 20 bytes were ever used (for conversion of numbers to character > strings mostly). From your map, it looks like that code may have been > rewritten in the newer shell, or perhaps one of your buffers at 16c9 or 174a > doesn't need to be as big as it is. > > Or, maybe the latest shell doesn't have any extra space at the end. > > As far as I could tell, the only *functional* change in the shell going > to the newer version was the addition of an extra routine in the jump > table. But, as you said, there was plenty of room for internal improve- > ments. > > --ray *** REPLACE THIS LINE WITH YOUR MESSAGE *** Does anyone have the latest memory map to the c-power (power-c) shell. I have noticed that the power-c c compiler by spinmaker has the same shell command as the c-power complier. also, is the C-power assembler source compliable under Power-c 128. Byron.
rayz@csustan.UUCP (R. L. Zarling) (10/14/87)
In article <608@inuxb.UUCP> star@inuxb.UUCP (Byron Johnson) writes: >... also, is the C-power assembler >source compliable under Power-c 128. > > Byron. Yes, the latest version of the C-power assembler will compile under either C-power 128 or C-power 64, by changing a #define. Apparently somewhere in going from version 2.0 to 2.1, unix compatiblity was lost however. I have recently completed another small revision of the C-power assembler, tentatively dubbed version 2.2. It incorporates a bit of minor streamlining and bug fixes, but the main change was to restore unix compatibility and add Amiga compatibility (are you there, Mark?). In addition, I am in the final stages of beta testing a linker, written in C, which does the same thing as the C-power linker, but runs on an Amiga. I have not yet tried the linker under Unix. An earlier version ran on C-power 64, so I assume that it could be made to work on the 64 or 128, too, although it would be slower than the standard linker on those machines. Yes, my linker *does* allow the possibility of getting a load map... The combination of the C-power assembler and the linker provide a complete cross-development package for the C64/128 running on an Amiga or Unix box. If anyone is interested in a copy of either the assembler or linker, send me a uucp path and it's yours. At this time, the linker should be considered pre-release, for beta testing. --ray zarling {seismo,ihnp4,...}!lll-crg!csustan!rayz
sentinel@killer.UUCP (10/20/87)
In article <981@csustan.UUCP> rayz@csustan.UUCP (R. L. Zarling) writes: > >If anyone is interested in a copy of either the assembler or linker, >send me a uucp path and it's yours. At this time, the linker should be >considered pre-release, for beta testing. > I'm having some problems getting mail to you. Can you please either post or mail me a copy of the new assembler and linker? Thanks, and I apologize to all for posting this... >--ray zarling > {seismo,ihnp4,...}!lll-crg!csustan!rayz -- Rob Tillotson ...ihnp4!killer!sentinel 3922-1 Newport Ave. -or- Fort Wayne, IN 46805 ...rutgers!unirot!sentinel (219) 483-2722 (top one preferred)