Jump to content
IGNORED

OSS cartridges


candle

Recommended Posts

perhaps this will be more convincing ;)

 

foocart.jpg

 

 

This cart looks f-SICK (!!!) :thumbsup:

 

I also noticed your Ethernet-ready design as well. I am assuming you can really read and write to that ram, and if that is the case, just a couple of questions:

 

1. Will this cart only work on XL or could it work on the 800 ("JayMiner") platform? (I have both machines)

2. If only works on the 800XL, could a version be made to work on the 800? Is a right-slot version a possibility, so the left-slot is used for anything else?

3. Could Ethernet be incorporated into this design (probably in second-generation of this cart)?

4. Can a battery-backup be considered for holding RAM content, while machine is off?

4. This cart would be PERFECT for running FujiX (the on-going GUI project)!

 

I also saw your massive, virtually plug-and-play 1Mb upgrade project (sick!). Keep up the great work.

 

Ready to burn some cash, here! :cool:

 

F.

Link to comment
Share on other sites

perhaps this will be more convincing ;)

 

foocart.jpg

 

 

Hi Candle,

 

I'm still interested. I agree it looks like we let the interest in it drop off. I think the last count was like 12 or 13 buys. Hopefully we can move a little closer to the magic #. Some people don't want an all in 1 monster card that does everything but the windows. Just one that does the floors and takes out the garbage. :lol:

Link to comment
Share on other sites

The problem with most of these carts seems to me to be their mutual exclusivity: i.e. ethernet or RAM cart or SpartaDOS X (for those using a MaxFlash SDX). Pass-thru ports go some way to resolving that situation, but then we have the problem of a huge stack of carts (especially troublesome on an XL). But such is the profusion of plug-in upgrade possibilities... off-hand:

 

  • SIDE/MyIDE cart
  • Ethernet Cart
  • RAM cart
  • SpartaDOS X (assuming not internally fitted, and on a MaxFlash cart, with no pass-thru)

One would ideally like all these upgrades to be plugged in at once. R-Time 8, SDX, and Diamond all had piggy-back capability back in the day, and I feel that short of building some kind of super-expensive uber-cart which features all of the above and more, being able to mix and match at least a couple of these carts is the way to go. With IntSDX, Ultimate 1MB, ARC Clock, etc, etc, we can no longer assume that such things aren't already present on the machine. I, for example, might use a GUI RAM-cart plus Ethernet on a machine which has Ultimate 1MB or IntSDX/ARC already fitted. A piggy-back RAM cart (which I have here) will fit the bill nicely

 

And my original question: can the BASIC replacement be augmented to house a banked 64KB cart? Therein lies the rather tantalising possibility of a machine which boots to the GUI desktop instead of BASIC (on-board RAM permitting).

Edited by flashjazzcat
Link to comment
Share on other sites

Sure it can.

You can implement any existing cart banking scheme on the BASIC ROM enable, instead of /S4 or /S5..

 

The only thing is, you are limited to the 8k adress range that BASIC uses ($A000-$BFFF)

 

The XEGS supercart banking scheme is good for up to 2megs, in 8k banks. And it'd be REAL EASY to do on a small board that plugs in the BASIC ROM socket.

Link to comment
Share on other sites

i think we all agree at one point

some kind of backplane (vide 1090) would help alot

it seems i'm runinng over and over the same obstacle - there is one cartridge slot, and making cartridges pass through is not realy an option

at some point you need more space behind your computer, than you have beside you

Link to comment
Share on other sites

Heres my oppinion..

 

A) Internal BASIC is pretty useless..

B) I hate plugging & unplugging carts.

C) I hate flash devices.

 

D) I hate running hacked OS roms..

 

So yeah, a version of that GUI that would run from a banked ROM in the BASIC socket sounds ideal for me. Holding OPTION while booting would disable it..

 

I Still don't see why you can't just load the thing from disk.. Even if its completely modular, hardisk interface access is just as fast as RAM/ROM/FLASH these days.. And having it completely disk based would provide the highest degree of flexibility..

Link to comment
Share on other sites

I agree, disk based is most flexible, but when you actually sit down and plan out how to run it from disk, it becomes extremely complex. Certainly, if I could rely on every user having a fast hard disk and running some form of SpartaDOS, many variable factors would be removed. However, running the GUI out of the Shadow RAM and swapping segments in and out from disk immediately rules out RealDOS, SpartaDOS 3.x, Turbo Basic, The Last Word, etc, etc, etc. There are also many difficulties associated with moving data in and out from under the OS, for obvious reasons. So, if we rule out the Shadow RAM, and we actually want to run some applications, we're left with the extended RAM region. Well - I've been through this as an internal monolgue and external dialogue many times elsewhere. It's not easy. Pound for pound, putting the GUI on a cart provides the most realistic chance of it ever getting finished and working in a useful way.

 

That's how it looks to me at the moment, anyway.

 

But yeah - having the thing built into the BASIC socket and bypassed with option sounds pretty cool. It's the kind of mod I'd be inclined to do.

 

Anyway: someone needs to start making four-way ECI/PBI cart adapters.:)

Edited by flashjazzcat
Link to comment
Share on other sites

I agree, disk based is most flexible, but when you actually sit down and plan out how to run it from disk, it becomes extremely complex. Certainly, if I could rely on every user having a fast hard disk and running some form of SpartaDOS, many variable factors would be removed. However, running the GUI out of the Shadow RAM and swapping segments in and out from disk immediately rules out RealDOS, SpartaDOS 3.x, Turbo Basic, The Last Word, etc, etc, etc. There are also many difficulties associated with moving data in and out from under the OS, for obvious reasons. So, if we rule out the Shadow RAM, and we actually want to run some applications, we're left with the extended RAM region. Well - I've been through this as an internal monolgue and external dialogue many times elsewhere. It's not easy. Pound for pound, putting the GUI on a cart provides the most realistic chance of it ever getting finished and working in a useful way.

 

That's how it looks to me at the moment, anyway.

 

But yeah - having the thing built into the BASIC socket and bypassed with option sounds pretty cool. It's the kind of mod I'd be inclined to do.

 

Anyway: someone needs to start making four-way ECI/PBI cart adapters.:)

 

You mean with 4 cart slots?

Link to comment
Share on other sites

Heres my oppinion..

 

A) Internal BASIC is pretty useless..

B) I hate plugging & unplugging carts.

C) I hate flash devices.

 

D) I hate running hacked OS roms..

 

So yeah, a version of that GUI that would run from a banked ROM in the BASIC socket sounds ideal for me. Holding OPTION while booting would disable it..

 

I Still don't see why you can't just load the thing from disk.. Even if its completely modular, hardisk interface access is just as fast as RAM/ROM/FLASH these days.. And having it completely disk based would provide the highest degree of flexibility..

 

EDIT: this post was meant to answer following this post: http://www.atariage.com/forums/topic/162486-oss-cartridges/page__view__findpost__p__2281917

 

It seems to me, after reading about so many fragmented/isolated HW upgrades initiatives/projects/products, that we are probably reaching a crucial point in time, with respect the actual use and longevity of this platform.

 

I would only cite the most critical drivers for reaching this juncture:

 

1. Most of us (especially those truly experienced with the HW/SW) are in mid-later 30s, 40s and even higher.

 

2. Even though the platform continues to provide real challenges and satisfaction, there is a BIG difference between its design and today's computational tools and solutions. The speed, the user interface, the connectivity, the applications, etc. This is affecting TREMENDOUSLY the perception of what computing means for today's youngest generation (for whom I feel sorry, because they will hardly be able to appreciate the value and depth of how far we have gone, and the beauty and joy of where we come from, and where it all started).

 

3. For the above reasons, we need to seriously face that, after we are done this "new lease" in life, we may take most of the passion and driving knowledge to our graves (it will be certainly difficult or unrealistic to assume that our next immediate generation will take on where we left it and continue for another 30-40 years, in several cycles. I think we will be done, after this temp. re-birth of interest).

 

 

Therefore, if we "integrate" all of above stuff, we end up with a tough scenario, and a pretty limited range of solutions, being SpartaDos-X and FujiX (maybe the LastWord) among the only ones that could help "bridge" future generations back into this world (where computing was, above everything, FUN). Anything else will look just TOO dissimilar, too disconnected in time-and-function with respect to the tools and computational environment of our present generation.

 

And that is precisely the shift that we may need to IMMEDIATELY consider: focus, entirely, on such key SW projects (yes, it starts with the SW), and then wrap them around with the appropriate/following HW, so we ensure longevity, usability and usefulness (at least from a research-perspective) of the platform.

 

Therefore, if a 1090-backplane (and supporting HW add-ons) is what is required to ensure that we can store and light-up INSTANTLY a version of FujiX, SpartaDosX, comprehensive system diagnostics, communications, and programming/maintenance utilities/framework, all-in-one, and all of this FULLY SOLID-STATE (no moving parts, so it lasts and "eternity"), then that's probably the way we should all go and put our money towards, so we don't end up with a disparate collection of HW and upgrades that, at the end, serve no cohesive/integrated or "survivable" purpose.

 

Just my humble opinion, though. My 0.02c.

 

F.

Edited by Faicuai
Link to comment
Share on other sites

Problem with 4 (or eight) carts is how does the machine select them? Otherwise, you can only use one at a time. Second problem, is that if youve got 4 carts plugged in, even though they may be inactive, you're adding MORE LOAD to the bus. I know you don't want/need me to go into THAT LECTURE again.. So yeah.. youd have to design a new hardware standard.. Which makes no sense at this point in the game.. No one will follow it in the future. Best thing to do is adhere to existing standards and make the absolute best of the resources. (my oppinion)

 

Flashjazzcat.. To me, this is the bottom line.. If you write your stuff so it requires custom hardware, you are severely limiting your user base. If you write it to only work with SDX, you are limting it again.. I'd avoid that at all costs if I was you. Make it where it can run from any "disk based" system, and let the end user worry about the speed of their shit.. IF its not fast enough for them, they can get a faster device to install it on. IF you have to require extended RAM, so be it. That's been an accepted standard for years, and no one expects mac-like functionality out of a 64k machine. As far as using the ram under the OS, I wouldn't do it. That 8k is much more valuable not touched, for compatabilty's sake than used for anything you could ever do with it.

Link to comment
Share on other sites

Re: Eight carts: Guess what - I was joking. :)

 

Re: special hardware. It's likely that the minimum requirement will be an AtariMax or any other banked flash cart, plus 128KB of on-board RAM. That's also about the minimum practical config for SpartaDOS X, which is also one of the most complex and capable pieces of software ever written for the A8. People want the power of SDX, they go out and buy a flash cart for it - simple as that.

 

The next step up is a flash cart with built-in RAM. This will benefit users who don't have on-board extended memory, and will hands down be the best way of running the GUI with legacy applications. The RAM cart is by no means essential, though.

 

As for the GUI requiring SpartaDOS X: I have never said it would, and repeatedly been obliged to remind people that it doesn't. However, I'll say it again.

 

The GUI does NOT require SpartaDOS X.

 

Ruling out use of the shadow RAM (which I heartily agree with) more or less obliges us to use a cart to get this thing to run on a 130XE (and that is an absolute requirement as far as I'm concerned). I've spent two years trying to shoe horn a 30KB word processor into the Atari, and putting the thing on a cart would probably have solved all my problems.

 

I am not, however, going to "tie" the GUI to any specific hardware. It'll run on an AtariMax 1Mb or 8Mb flash cart, Sic! Cart, Turbo Freezer, Steve's RAM cart, etc, etc, etc. That's assuming I can fit everything in the RAM that's left. But given the scale of the undertaking and the difficulties involved, I think that's just about as flexible as I can be expected to be. Hard disks or not, there's a reason stuff like SpartaDOS X was and still is delivered via cartridge. There's a lot more to it than just a few banks of ROM mapped out like a disk drive.

 

As for GUIs which require an HDD... TRS Desktop.

Edited by flashjazzcat
Link to comment
Share on other sites

In my Oppinion, SDX is the only OS worth using that doesn't use the RAM under the OS..

 

Fiberwire.. Could you please refrain from making useless posts? It's very annoying in the middle of a discussion, your humor is retarded, and it needlessly inflates the thread. Go do that in one of your Corvus threads..

Link to comment
Share on other sites

In my Opinion, SDX is the only OS worth using that doesn't use the RAM under the OS..

I completely agree, up to and including the word "using". :D

 

SDX can use the RAM under the OS, and will by default if you have 128KB and don't use a custom CONFIG.SYS, or have no extended RAM at all. That flexibility alone demonstrates just how well written it is.

Edited by flashjazzcat
Link to comment
Share on other sites

Re: Eight carts: Guess what - I was joking. :)

 

The next step up is a flash cart with built-in RAM. This will benefit users who don't have on-board extended memory, and will hands down be the best way of running the GUI with legacy applications. The RAM cart is by no means essential, though.

 

Precisely. And not only that, a cart can be fired with the computer, its power-supply and any suitable screen. No HW drives, no mechanical components, can be immediately and easily plugged-in, etc. Nothing can beat that, unless permanently resident in ROM (but that requires opening and modification).

 

 

I am not, however, going to "tie" the GUI to any specific hardware. It'll run on an AtariMax 1Mb or 8Mb flash cart, Sic! Cart, Turbo Freezer, Steve's RAM cart, etc, etc, etc. That's assuming I can fit everything in the RAM that's left.

 

You are already doing it. It is unavoidable. One way or another, extra hardware WILL BE mandatory, so the SW product's evolution is not permanently capped.

 

 

The Cart-concept is probably the way to go, for most of the folks.

 

F.

Link to comment
Share on other sites

  • 9 months later...

candle, I've been looking around the forum for days to find a supercart like this which would let me have my cake and eat it too (SDX + RTC + 4 OSS and some extra RAM....yay :party:) , unfortunately the thread seems to have come to a screeching halt due to lack of interest :_(. Would it help if I say put me down for 2... would we be anywhere near required units???

Edited by atari8warez
Link to comment
Share on other sites

  • 9 months later...
  • 5 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...