New 128 BBS moving forward

[David Nelson]

An optimistic title, but I hope it got your attention. I've been away for awhile and I'm in a lousy situation right now. Long story short my new house is in one county and I'm still working in another. Transfer is on file but may take ... awhile ... so my online time is limited and my Commodore (and Amiga) gear is not with me. Nor are my programming guides. Only programming going on right now is in Visual Studio.

Anyway, I'm shocked that nothing seems to have happened while I have been in limbo. Here's what I remember having been discussed thus far:

Hardware was settled on as a 128 with either two 1571's or a 1581. We were aiming to use 80 column fast mode (2mhz). Vice was the chosen emulator. There'd be no dial up support, only telnet. A Pc would be involved to handle connections and some other custom advanced features. That PC software was to be in .NET and C#. The 128 code was to be done in CA65/CC65.

Since then, we learned CA65/CC65 isn't very 128-friendly. We also learned that VICE isn't quite as good a 128 emulator as it is a 64 emulator. But it seems like it can mostly get the job done. Maybe.

What to do, what to do. First, is there still any interest now that we've learned it won't be as easy as we thought? I'm itching to try out a few things, but I don't see much happening until I get my transfer. My two days home a week will be consumed by family time, leaving very little time for the hobby. I have tried using VICE and it just frustrates me. I'd rather sit at the real thing I guess. With my programming guides scattered all around me. My 128 basic is rusty, and my ML even rustier, but that's all just part of the fun.

Thanks,
-David

[OzOne]

Seems to be a couple of posts regarding this. I'm still interested too. Would be happy if we can do this in basic/ml (what I'm familiar with!) and then compile it for the release.

Should we be going back to regularly scheduled meeting ? I seem to recall that the time was an issue for some people though ?

Oz

[David Nelson]

I probably wouldn't be able to attend very many online meetings, but as long as a transcript is posted I could keep up. I guess maybe I should find a tutorial on how to use VICE. Then with tcpser I could go the emulation route for the time being until I get back home permanently. I guess basic/ml is the route now then.

[Blacklord]

I probably wouldn't be able to attend very many online meetings, but as long as a transcript is posted I could keep up. I guess maybe I should find a tutorial on how to use VICE. Then with tcpser I could go the emulation route for the time being until I get back home permanently. I guess basic/ml is the route now then.

Well I guess it comes down to when people can attend - suggestions guys ?

cheers,

Lance

[David Nelson]

Well I guess it comes down to when people can attend - suggestions guys ?

The online meetings were a good idea, but I guess we're all trying to play with this idea in what little spare time we have. Back and forth messages like this work for now.

[Pinacolada]

Ping? Any progress on this BBS?

[Blacklord]

Ping? Any progress on this BBS?

Think we've all put this into the "too hard" basket.

Lance

[Andrew Wiskow]

I've got my BBS up and running now on a 128 with a Lt. Kernal hard drive, in 80 columns!  :-)

I was able to track down Nick Smith, the author of All American BBS (which is the software I'm running), and I got him to agree to release both 64 and 128 versions of his BBS, as well as the source code for each, to the Public Domain.  I only mention all this in the event that there IS still interest in this project, perhaps whoever takes it on could make use of some of the source code as a sort of "starting point".  You can find all of this in d64 files on my BBS's website at http://hometown.aol.com/cottonwoodbbs

-Andrew

[David Nelson]

Ping? Any progress on this BBS?

Life got a bit too busy for me suddenly; maybe when things calm down a bit later this year...

[Pinacolada]

Shucks... I can understand that. Well, maybe over summer I'll take another look at fixing a few things in Centipede 128... I really need to practice my C128 BASIC coding...

[hydrophilic]

Centipede in BASIC !?

The arcade version is a *very* fast-paced game.  Would like to see how you do that with BASIC.  I've managed to reserrect a few BASIC games I wrote back in the day and they run like most people would expect, not fast (in a few cases quite slow).

[Pinacolada]

No, it's a BBS program.

[Blacklord]

Okay.......


Watch this space in the next few days, I'm just about to put up a hand-rolled BBS..... & yes, it's on a 128 that's connected via telbbs to the net.....

I've tentatively titled it Alive! BBS (gee, wonder where that name came from.....)

Release 0.01 has the following :

16 message areas
16 file areas
Limit of 1,000 users (should be enough I'm thinking....)
Maximum of 9,999 messages
Written in assembly, so it's fast (Merlin 128)
Works only on the 2MHz mode of the 128, supports 1581 partitions & up to 3 drives (because I have an internal 1571 & two 1581's......)

Limitations :

Currently in glorious ASCII only
File transfers appear to be somewhat broken
4k message size (that'll teach everyone to be straight to the point!)
Hard coded menus
Broken in VICE
Message base is a flat SEQ file so it slows a bit on message searching
No door support
Has date "issues" (seems to think that the year is always 2010)

Planned for release 0.02

ANSI

Further down the line :

PETSCII, polls, customisable menus, doors, hard drive support

It's really only a "proof of concept" at the moment but it keeps me outta trouble I guess.....

[Andrew Wiskow]

Okay.......


Watch this space in the next few days, I'm just about to put up a hand-rolled BBS..... & yes, it's on a 128 that's connected via telbbs to the net.....

Hmm... It's been more than a few days...  Did you give up on this idea?  I saw your ad on the alt.bbs.ads newsgroup for Landover Amiga BBS, so I'm guessing you may have given up on this idea.  Or were you planning on running two BBS's at the same time?

-Andrew

[Blacklord]

Okay.......


Watch this space in the next few days, I'm just about to put up a hand-rolled BBS..... & yes, it's on a 128 that's connected via telbbs to the net.....

Hmm... It's been more than a few days...  Did you give up on this idea?  I saw your ad on the alt.bbs.ads newsgroup for Landover Amiga BBS, so I'm guessing you may have given up on this idea.  Or were you planning on running two BBS's at the same time?

-Andrew

I'm a hopeless tweaker - decided I wanted to finish off some of the broken features first :ironisk:

Naturally, I haven't had the time.....


May be I should just put it up anyway......

Lance

[BillBuckels]

Running Overlays in The Upper Bank - A Question and a Comment or Two

I saw some talk of this BBS being written in CC65. I am a little curious (just a little mind you) as to whether CC65 allows the use of OVERLAYS like Aztec C65 does (in fact all of Aztec C Compilers do)?

All kidding aside, if the compiler allows overlays and explicit memory holes with which to load those overlays you can just page the things in and out of your upper memory banks into your overlay hole and run them. Just modify your overlay loader.

The Aztec-C stuff has always provided open source for their overlays as well as their library routines. If the CC65 stuff is the same just add the routines to load the overlays from the bank switch instead of from disk.

This would be fairly trivial.

I don't know how to bank switch on the C128. You may want to send me some email on that and also what the differences are for setting up zero page and starting executable modules from BASIC 7. I haven't mucked with this part much. I could probably whip-off an Aztec C version of an overlay manager that loads overlays from the upper banks in an evening or 3.

Now, I recall seeing that there was some comparison of doing this to writing an OS. I hardly think so, unless I am missing something.

If nobody here has looked at how to write, launch and use overlays the complete source is on my website along with the compiler. The only source that isn't there is the source for the compiler, assembler, and linker.

Overlay Example

The Loader

Code Select Expand



/* Copyright (c) 1983 by Manx Software Systems, Inc. */
/*  Fixups Copyright (c) 2007 by Bill Buckels */
#define E_OVSMALL -5
#define E_NOMEM -6

int errno;

ovloader(ovname, args)
char *ovname;
{
register int fd;
register char *topmem;
char *ovaddr;
unsigned ovsize;
register int (*ovbgn)();
char buf[30];
char *settop();

strcpy(buf, ovname);
again:
strcat(buf, ".OVR");
if ((fd = open(buf, 0)) < 0)
return -1;
if (read(fd, &ovaddr, 2) <= 0)
goto bad;
if (read(fd, &ovsize, 2) <= 0)
goto bad;
topmem = settop(0);
if (topmem < ovaddr + ovsize) {
if (settop(ovaddr + ovsize - topmem) == 0) {
errno = E_NOMEM;
goto bad;
}
}
if (read(fd, ovaddr, ovsize) < ovsize) {
if (errno == 0)
errno = E_OVSMALL;
bad:
close(fd);
return(-1);
}
close(fd);
ovbgn = ovaddr;
return((*ovbgn)());

}




The Launcher for Ovmain

Code Select Expand



*:ts=8
*
* Copyright (c) 1983 by Manx Software Systems, Inc.
*
instxt "zpage.h"
*
* These routines assume that the ovld routine was compiled with C65.
*
*
public .ovbgn
entry .ovbgn
public ovexit_
ext ovmain_
ext .cret
*
dseg
ovstkpt rmb 2 ;save old frame pointer for ovexit
*
cseg
.ovbgn
pla ;throw away return address
pla
inc LFRAME+1 ;point at regs
ldy #8
lda (AFRAME),Y ;get number of regs saved
tay
beq ovb2 ;none, skip
dey
ovb1 lda (LFRAME),Y ;restore the registers
sta REGS,Y
dey
bpl ovb1
ovb2 lda AFRAME ;pointer to frame
sta ovstkpt ;save it for ovexit
sta R1
lda AFRAME+1
sta ovstkpt+1
sta R1+1
ldy #7
ovb3 lda (R1),Y ;restore the frame
sta VAL,Y
dey
bpl ovb3
ldy VAL+1
ldx VAL ;dec the return address
bne ovb4
dey
ovb4 dex
tya ;put back on stack
pha
txa ; so it looks like the call
pha ;  was direct to ovmain
jmp ovmain_
*
ovexit_
pla ;throw away return
pla
ldy #0 ;get return value
lda (SP),Y
sta R0
iny
lda (SP),Y
sta R0+1
sec
lda ovstkpt ;get original frame pointer
sta AFRAME
sbc #1 ;sub one to get back to number of regs
sta R1
lda ovstkpt+1
sta AFRAME+1
sbc #0
sta R1+1
ldy #0
lda (R1),Y ;got number of regs
sta VAL ;save for sub
sec
lda AFRAME
sbc VAL ;drop AFRAME by size of regs + 256
sta LFRAME ;and that's LFRAME
lda AFRAME+1
sbc #1
sta LFRAME+1 ;and now everything's set up for cret to
jmp .cret# ; do it's thing
*



I think you get the point. I am not going to post the whole sample but there is another very complete and large overlay project also bundled with the compiler. The only hitch is that this is for the C64 and when I get the time and some help I will port it to the C128 but first things first and I am working on some other compiler bundles that I want to make available.

Again, it seems straight forward to me that you would just load your overlays in the upper bank on program start the same way I load my bitmapped graphics libraries over on the Apple II in Aztec C for ProDOS (this compiler and that code are also on my Aztec C website) and then switch them in and out as required. Just like having a RAM disk or how I used to do my graphics back in the EMM days on the PC.

I am going to run along now, and this thread and others about using CC65 are somewhat interesting but I'd really like some help putting my Aztec C into shape for the C128. (It does floating point too BTW) and I can work on my Windows Box and I am finally getting my money's worth for the license which was quite expensive:)

The CC65 is too nixey for me I think.

Later,

Bill

http://www.clipshop.ca/Aztec/index.htm#commodore

[BigDumbDinosaur]

This might help you get started on the 128's memory gyrations...

Code Select Expand


;===============================================================================
;
;8722 MEMORY MANAGEMENT UNIT
;
mmu      =$d500                ;configuration reg in I/O block
mmuhi    =$ff00                ;configuration reg in hi RAM
;
mmucr    =mmuhi                ;configuration...
;
; 0xxxxxxx
; |||||||
; ||||||+---> $D000-$DFFF:  0 = I/O hardware
; ||||||                    1 = RAM or character ROM
; |||||+----> $4000-$7FFF:  0 = system ROM
; |||||                     1 = RAM
; |||++-----> $8000-$BFFF: 00 = system ROM
; |||                      01 = internal function ROM
; |||                      10 = external function ROM
; |||                      11 = RAM
; |++-------> $C000-$FFFF: 00 = system ROM
; |                        01 = internal function ROM
; |                        10 = external function ROM
; |                        11 = RAM
; +---------> RAM bank:     0 = RAM-0
;                            1 = RAM-1
;
pcra     =mmu+1                ;preconfiguration A
pcrb     =mmu+2                ;preconfiguration B
pcrc     =mmu+3                ;preconfiguration C
pcrd     =mmu+4                ;preconfiguration D
mmumcr   =mmu+5                ;mode configuration...
;
; xxxxx00x
; |||||  |
; |||||  +---> active MPU: 0 = Z80
; |||||                    1 = 8502
; ||||+------> FSDIR (fast serial control)
; |||+-------> /GAME
; ||+--------> /EXROM
; |+---------> ROM select: 0 = C-128
; |                        1 = C-64
; +----------> 40/80 key:  0 = 80 (down)
;                          1 = 40 (up)
;
mmurcr   =mmu+6                ;memory map configuration...
;
; 0x00xxxx
; |  ||||
; |  ||++---> common RAM size: 00 =  1K
; |  ||                        01 =  4K
; |  ||                        10 =  8K
; |  ||                        11 = 16K
; |  ++-----> common RAM area: 00 = none
; |                            01 = bottom
; |                            10 = top
; |                            11 = both
; +---------> VIC video bank: 0 = RAM-0
;                              1 = RAM-1
;
mmup0l   =mmu+7                ;virtual zero page location
mmup0h   =mmu+8                ;virtual zero page RAM bank
mmup1l   =mmu+9                ;virtual MPU stack location
mmup1h   =mmu+10               ;virtual MPU stack RAM bank
;
lcra     =mmucr+1              ;select configuration A
lcrb     =mmucr+2              ;select configuration B
lcrc     =mmucr+3              ;select configuration C
lcrd     =mmucr+4              ;select configuration D
;


Note that in most programs the configuration register at $FF00 is the one to use for manipulating the memory map.  Obviously, if the I/O block is mapped out you can't get to the MMU in the $D000 range.  MMUCR and LCRA-LCRD can never be mapped out.

[BillBuckels]

Thanks. I was reading a little about how all this works. But I will need to start at the beginning and determine what tokens to append to a C program and how to load it on the C128 the same way I do on the C64 and then there is the matter of memorizing the memory map the same way I did on the C64 and blah blah blah...

On this memory stuff the overlays being stored in the upper banks is definitely doable as is a mixture of code and data depending on what a person wishes to do.

The writing of the overlay code only takes a minute or so as you know... the learning of the hardware takes the time so I am grateful for having mucked with the C64 since this will give me a starting point.

I hope to get my CP/M 80 stuff out of the way first. So I am wondering what kind of bios reference and memory map resources there are for the c128 and have dloaded lots and lots of stuff to devour.

I am also wondering why I can't access the screen memory directly in CP/M 3 so I will toddle off to learn a little more and put this other on the back-burner. And how to programatically set to 80 col mode and if the Vice emulator will handle this.


Cheers,

Bill

[BigDumbDinosaur]

I hope to get my CP/M 80 stuff out of the way first. So I am wondering what kind of bios reference and memory map resources there are for the c128 and have dloaded lots and lots of stuff to devour.

Look in the downloads area for Mapping the Commodore 128.  The file is an OCRed PDF with a  few boo-boos, but is eminently readable.

I am also wondering why I can't access the screen memory directly in CP/M 3 so I will toddle off to learn a little more and put this other on the back-burner. And how to programatically set to 80 col mode and if the Vice emulator will handle this.

Are your referring to the VDC's local video RAM?  That has to be accessed indirectly through the VDC's registers.  If you are familiar with how the 6545 CRTC works, then you will understand the basics.  Again, Mapping the Commodore 128 will be of help.  In 128 mode, screen kernel routines can be called to manipulate the VDC.  I haven't a clue how that's done in CP/M, although I suspect it's buried somewhere in the BIOS.

Speaking of the VDC...

Code Select Expand


vdc      =$d600                ;8563/68 video display controller
;
;===============================================================================
;
;8563/68 VIDEO DISPLAY CONTROLLER DECLARATIONS
;
vdcadr   =vdc                  ;setup (write)/status (read) port...
;
; ---------------------------------------------------
; write: selects internal register to access
; read:  reports VDC status...
;
; xxx11xxx
; |||  |||
; |||  +++---> chip version (meaning unknown)
; ||+--------> 1 = vertical retrace in progress
; |+---------> 1 = light pen location latched
; +----------> 1 = selected register ready for access
; ---------------------------------------------------
;
vdcdat   =vdcadr+1             ;read/write register port
;
;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;
; ----------------------------------
; | 8563/68 VDC Internal Registers |
; ----------------------------------
;
coltot   =0                    ;total character columns
colvis   =1                    ;visible character columns
hsypos   =2                    ;horizontal sync position
hvsyw    =3                    ;horizontal & vertical sync width...
;
; xxxxxxxx
; ||||||||
; ||||++++---> horizontal sync pulse
; ++++-------> vertical sync pulse
;
rowtot   =4                    ;total character rows
vfadj    =5                    ;vertical fine adjustment
rowvis   =6                    ;visible character rows
vsypos   =7                    ;vertical sync position
ilcctl   =8                    ;interlace mode control...
;
; 11111100
;       ||
;       ++---> 00 = non-interlace (default)
;              01 = interlace sync (double offset scan)
;              10 = no interlace
;              11 = interlace sync & video (alternating half-frames)
;
nsclpc   =9                    ;scan lines per character
csrctl   =10                   ;cursor mode control
csrbsl   =11                   ;cursor bottom scan line
dmemhi   =12                   ;start of display RAM (MSB)
dmemlo   =13                   ;start of display RAM (LSB)
cposhi   =14                   ;cursor position (MSB)
cposlo   =15                   ;cursor position (LSB)
lpvpos   =16                   ;light pen vertical position
lphpos   =17                   ;light pen horizontal position
vramhi   =18                   ;video RAM address (MSB), autoincrements
vramlo   =19                   ;video RAM address (LSB), autoincrements
amemhi   =20                   ;start of attribute RAM (MSB)
amemlo   =21                   ;start of attribute RAM (LSB)
hcsiz    =22                   ;character horizontal size...
;
; xxxxxxxx
; ||||||||
; ||||++++---> pixels per display character: default = %00001000
; ++++-------> pixels in character cell:     default = %01110000
;
vcsiz    =23                   ;character vertical size control...
;
; 111xxxxx
;    |||||
;    +++++---> scan lines in character cell: default = %00001000
;
vsscr    =24                   ;vertical smooth scroll & control...
;
; xxxxxxxx
; ||||||||
; |||+++++---> vertical smooth scroll
; ||+--------> 1 = slow character blinking rate (default)
; |+---------> 1 = foreground/background reversed (default = 0)
; +----------> 0 = fill RAM, 1 = copy RAM
;
hsscr    =25                   ;horizontal smooth scroll & control...
;
; xxxxxxxx
; ||||||||
; ||||++++---> horizontal smooth scroll
; |||+-------> 1 = double pixel size
; ||+--------> 1 = semi-graphic mode on
; |+---------> 1 = character attribute mode on (default)
; +----------> 0 = character mode (default), 1 = bitmap mode
;
fgbgat   =26                   ;foreground/background color...
;
; xxxxxxxx
; ||||||||
; ||||++++---> background color (RGBI)
; ++++-------> foreground color (RGBI)
;
rowain   =27                   ;row address increment value
kramad   =28                   ;font RAM start address & RAM type...
;
; xxxx1111
; ||||
; |||+-------> 0 = 4416 DRAM (16K), 1 = 4464 (64K)
; +++--------> font RAM page address
;
ulslp    =29                   ;underline scan line position
blkbyt   =30                   ;number of bytes for block copy/fill
vramrw   =31                   ;video RAM read/write access
bsrchi   =32                   ;block copy source address (MSB)
bsrclo   =33                   ;block copy source address (LSB)
hbposl   =34                   ;left horizontal blanking position
hbposr   =35                   ;right horizontal blanking position
dramrf   =36                   ;DRAM refresh cycles per scan line
;