Basic hardware requirements

[Blacklord]

My suggestions :

Basic :

Stock 128, 64k VDC, 80 column mode, 1571

Optional:

REU, 1581, hard drive

Emulation :

VICE 128 & whatever you can throw at it

Modem :

Minimum 2400 baud, 9600 or faster preferred, telnet via X86 host (would be an essential requirement IMHO)

[Guest]

Please don't require 64k VDC.  I see it as a great option for caching data if it's available, but I'll probably run a system with this and my target 128 is a flat one with 16k VDC.  I do think, however, we may get a lot of legs by requiring JiffyDOS.  I've been itching to write a JiffyDOS library in CC65, so this would give me a perfect excuse to get started.

I also think we should decide early on whether or not to support both the user port and turbo232 in the initial release.  Yes, make it modular, but I think our testing should be done against turbo232/swiftlink.  VICE gives us emulation for that and most sysops have at least one of these laying around.  

To me, here's the minimum requirements:

128 w/16k VDC & JiffyDOS
1581 Disk Drive
SwiftLink/Turbo232
80-column monitor (no VIC-II support, run in FAST mode all the time!)
Joystick (sysop menu navigation)

Release one optional equipment:

128 w/64k VDC
1571 (cannot be only drive)
1541 w/JiffyDOS (cannot be only drive)
CMD FD-Series
CMD HD-Series
CMD RamLink
1351 Mouse (sysop menu navigation)

I don't think REU support is wise because it will conflict with the requirement to use a Swiftlink/Turbo232.  A CMD RamLink will give you the ability to use BOTH and since it's a disk drive, we don't have to keep an REU driver in memory.  

Requiring a 1581 gives us 800k to squeeze in the whole system, including data.  I just don't think a single dual-sided 1571 disk will be big enough, and the latency will just kill any performance gains of using the 128.  A 1571 or 1541 (w/Jiffy) may be ok for extra storage (downloads), but anything that will be getting hit often should at least be on a 1581.

I think it's important for us to nail down hardware requirements before features so that we can create a complete memory map which will help us decide how to lay out the system software and variable memory.

[xlar54]

My suggestion on requirements matches with plbyrd, with the addition of plain RS232 / Hayes Userport modems.  They are slower, but more people have them than T232/Swiftlink, and a simple RS232 interface to a PC via the userport will allow a very good connection (I often Desterm BBSs at 28..

The drive issue... I dont think its unreasonable to expect _at least_ a 1581 to run the thing. If you're a Sysop and are running from a 1541, then you wont be running a BBS for too long But unless we look specifically for the drive type, I cant think of any way we can keep it from running on those other drives, if it all will fit. So maybe thats a "strongly suggested 1581 or better"?

REU shouldn't be a requirement, but something that can be used if it exists. Maybe as a RAM disk or a caching mechanism, if its available.  Just treat it as a regular drive and have an optional RAMDOS driver?  Mostly just for static data though (menus, etc

I agree with the 80 col requirment.  VIC-II not needed.

I like the optionals. I dont know much about the drives, but we can have a translation layer that will utilize the best drive commands for a particular unit.

We might want to consider cursor keys for menu navigation and joystick/mouse as optional.

[Blacklord]

Please don't require 64k VDC.  I see it as a great option for caching data if it's available, but I'll probably run a system with this and my target 128 is a flat one with 16k VDC.  I do think, however, we may get a lot of legs by requiring JiffyDOS.  I've been itching to write a JiffyDOS library in CC65, so this would give me a perfect excuse to get started.

Does everyone have JiffyDOS though ? Would we be blocking out people who don't have that option ?

I also think we should decide early on whether or not to support both the user port and turbo232 in the initial release.  Yes, make it modular, but I think our testing should be done against turbo232/swiftlink.  VICE gives us emulation for that and most sysops have at least one of these laying around.

True.  

128 w/16k VDC & JiffyDOS
1581 Disk Drive
SwiftLink/Turbo232
80-column monitor (no VIC-II support, run in FAST mode all the time!)
Joystick (sysop menu navigation)

The 1581 really should be an option, although these are common in the USA, they are rare to vanishing in other areas - for example, here in Australia.

I don't think REU support is wise because it will conflict with the requirement to use a Swiftlink/Turbo232.  A CMD RamLink will give you the ability to use BOTH and since it's a disk drive, we don't have to keep an REU driver in memory.

Same problem as the 1581, common in the US, but not elsewhere, still thinking that an REU provides better compatibility with more people.  

cheers,

Lance

[Guest]

REU causes us to loose a considerable amount of system RAM unless we are going to use the kernal routines to go after the memory directly and not use it as a RAM disk.  It also means that if you have a RamLink you can forget using the REU as a kernel programmable REU because the RamLink swallows that puppy up as more RAM for itself.

Running a BBS is a commitment.  If we design for lowest common denominator we probably won't achieve anything any better than any of the existing BBSs.  Those who don't want to buy the hardware can use VICE to emulate the specialized components.

[David Nelson]

Does everyone have JiffyDOS though ? Would we be blocking out people who don't have that option ?

LOL I don't have JiffyDOS. I'd need to buy for a 128D's internal 1571, two regular 1571's and a 1581. Adds up $$$.
For compatibility, 1581 and REU should be nice optional equipment to have. Even if to just use the REU as cache as was mentioned. Not everyone has a Turbo232/Swiftlink either (like me  are they still sold anywhere?) nor CMD Ramlink, or harddrives. We should focus on a plain vanilla stock 128 first, and all the other awesome ideas for supporting equipment are icing on the cake. If people have them let's take advantage of them, but let's not leave anyone behind, either.

Stock flat 128 and a 1571. 1541 and 1541-II's just won't do, sorry. Is there a way to query the drive and verify, perhaps by its ROM revision or other info it returns?

-David

[David Nelson]

Running a BBS is a commitment.  If we design for lowest common denominator we probably won't achieve anything any better than any of the existing BBSs.  Those who don't want to buy the hardware can use VICE to emulate the specialized components.

Good points on the REU and RamLink. Makes sense. But I still don't think it's wise to leave people behind. What we have in mind is far better than anything out there so far. See how far we can push what's available. In some way, I wonder what the point of an awesome new BBS is if it won't run on my native hardware (I.E. not having the hardware have to use VICE). It'd be a shame to have my rather plane jane C128D physically sitting here staring at me while running a "Commodore" BBS on VICE on my Dell computer. Just doesn't seem so retro... Might as well just dig up some old PC based BBS and modify it and run it natively under Windows. Just my opinion. I'd like a new Commodore BBS to actually run on the physical hardware that most people can throw together.

-David

[Blacklord]

Hi David,

Stock flat 128 and a 1571. 1541 and 1541-II's just won't do, sorry. Is there a way to query the drive and verify, perhaps by its ROM revision or other info it returns?

-David

Yes you can, if the condition isn't met, you can have the program display an error message & exit gracefully. Will hunt down the code I have stored away somewhere that does this.

Lance

[Guest]

Running a BBS is a commitment.  If we design for lowest common denominator we probably won't achieve anything any better than any of the existing BBSs.  Those who don't want to buy the hardware can use VICE to emulate the specialized components.

Good points on the REU and RamLink. Makes sense. But I still don't think it's wise to leave people behind. What we have in mind is far better than anything out there so far. See how far we can push what's available. In some way, I wonder what the point of an awesome new BBS is if it won't run on my native hardware (I.E. not having the hardware have to use VICE). It'd be a shame to have my rather plane jane C128D physically sitting here staring at me while running a "Commodore" BBS on VICE on my Dell computer. Just doesn't seem so retro... Might as well just dig up some old PC based BBS and modify it and run it natively under Windows. Just my opinion. I'd like a new Commodore BBS to actually run on the physical hardware that most people can throw together.

-David

Centipede is actually open source and freely available; plus it's damned good software.  We'll be very hard pressed to make a better BBS.  I think it is very reasonable to make some minimum qualifications that would help us make a better BBS.  Centipede won't work with less than at least one 1581 disk drive, and I don't think it's asking too much for a sysop to invest in some minimum equipment.

Maybe we can make it where it's 64HDD friendly.  That will be about as slow as a stock 1541, but at least it won't have head movement latency and will offer a lot of space for non-REL files.  But we'll still need a relatively large and speedy drive to host the REL file for the user database.  The only good alternative to a REL file is to wait for Maurice's upgrades to JiffyDOS that allow truly random file access to SEQ and PRG files, but that's a whole lot more difficult to require than a 1581.

[David Nelson]

OK, the Swiftlink I nabbed off of Ebay arrived. I think I'm in business. CMD's store only has the Turbo232 listed at $48+S/H. When they're out of stock, it sometimes takes awhile to get new ones made because of problems sourcing some of the components. Understandable -- I've had a heck of a time trying to find replacement chips for old projects sometimes and then trying to figure out what new components are drop-in replacements.

But I digress. Back to the point. I read somewhere (can't recall the link right now) that the max for the Commodore's native serial port is 19,200 bps. If it's actually possible to program at that rate, or even 9600, would a Swiftlink or Turbo232 really be necessary? I'm not sure how common these items are outside the US. Hopefully somebody can advise on that.

I imagine the quality of the serial adapter and cable is going to have some impact on that speed. And we don't really want to drop the speed down much or it'll start to feel real sluggish. But the question now is... given the speed of the 1571 in burst mode and the 128 running at 2mhz, how much of a delay will there be anyhow when the 128 goes to fetch another module or load something from disk? That lag is unavoidable. Would I be more likely to notice the lag if the BBS is cruising at 38,400 and all of a sudden there's a long pause or at 4800 and then a pause? I have a migraine right now so I may not be phrasing my question right. I hope somebody gets the jist of it.

Thanks



-David

[Guest]

Unless you have a BBS completely memorized and are staying way ahead of the menus with the keyboard, you really won't notice the lag.  And if we do things right, (and I hope we do) then you'll be far happier at 38,400 than 9600 (the best reasonable rate on a 2mhz 128 through the userport) when you start factoring in calls to the PC for data from SQL sources.

The drivers for the SwiftLink/Turbo232 are actually smaller and easier to deal with than the routines for the user port.  You simply set some registers on the device and allocate the buffer.  I'm going to hunt for some assembler to accomplish this.  I think there may already be a CC65 based driver for the SwiftLink and Turbo232.  Also, there are clone carts that have plans freely available on the net.  I believe Jim Brain created one and others have as well.

[David Nelson]

The Swiftlink's developers manual had some sample assembly code to show how to program and use the Swiftlink.

-David