Side2 with U1MB

[Jeffrey Worley]

I'm  a bit confused about the relationship between the Side2 and  the u1mb.  I used the Side2 for some weeks before getting the u1mb and really liked it a lot.  After the U1mb I like it even more, because it becomes a PBI hard disk (CF) interface, opening up the machine considerably.

 

Since the U1MB is installed I'm unable to access the OSS carts I burned into the Side2 cart.  In the U1MB bios there is a 'side2 rom enable/disable' function, but it is greyed out.  When I run Uflash the program says the Side2 hardware is not present.  When I run SideCFG, the program reports that the cart is present, lists the contents of the rom and tells me that the rom I have selected still is BasicXL, which is what this message is really about, as I'd like to use the cart functions of the Side2 to provide BasicXL for me to run my board, which is in beta right now at techccs.net 10001, running on Atari Basic presently.

 

Can anyone shed some light on this relationship and how I might make better use of the 1/2 meg of rom on the Side2 that has been largely supplanted by the rom onboard the u1mb?

 

best,

 

Jeff

[Roydea6]

 

Bios screen #3 ATR swap button Disabled.  this will un grey the Side Rom select on Bios screen #1.

 

 

 

[Faicuai]

1 hour ago, Technoid Mutant said:

I'm  a bit confused about the relationship between the Side2 and  the u1mb.  I used the Side2 for some weeks before getting the u1mb and really liked it a lot.  After the U1mb I like it even more, because it becomes a PBI hard disk (CF) interface, opening up the machine considerably.

 

Since the U1MB is installed I'm unable to access the OSS carts I burned into the Side2 cart.  In the U1MB bios there is a 'side2 rom enable/disable' function, but it is greyed out.  When I run Uflash the program says the Side2 hardware is not present.  When I run SideCFG, the program reports that the cart is present, lists the contents of the rom and tells me that the rom I have selected still is BasicXL, which is what this message is really about, as I'd like to use the cart functions of the Side2 to provide BasicXL for me to run my board, which is in beta right now at techccs.net 10001, running on Atari Basic presently.

 

Can anyone shed some light on this relationship and how I might make better use of the 1/2 meg of rom on the Side2 that has been largely supplanted by the rom onboard the u1mb?

 

best,

 

Jeff

Well, there are two things you need to keep an eye on:

 

1. How SIDE interacts (interdependently) with Ultimate-1MB

2. How SIDE behave on its own.

 

With respect to #2, there is a switch / lever with two positions on SIDE, which defines its operating mode: when the switch is UP, it behaves as a mass-storage device (and now as a "smart" cartridge as well), and when the switch is DOWN, it behaves as a SDX boot-cart.

 

Now, with respect to #1 above, here's where things become tricky: if you enable "Hard Disk" or "PBI Bios" options on Ultimate's BIOS configuration, you will access SIDE as a mass-storage device. However, if you wish to access SIDE as a smart-cart, or simply boot ANY other cart plugged in, you MUST first DISABLE "Hard Disk" or "PBI Bios" options on Ultimate BIOS menu, and then click the "cart-reset / switch" button (top-left of SIDE2) if the cart plugged is SIDE (so you can now see the SIDE's ROM-cart space).  NOTE: In addition to the above, and after disabling "Hard Disk" or "PBI Bios", you could also switch SIDE to SDX mode, and boot SDX as external cart (not from Ultimate). Once there, you will be able to access, immediately, the smart-cart ROM space of SIDE, concurrently with its internal SDX rom-space.

 

BTW, this is in HUGE contrast with 800/Incognito, which is what I force myself to remember every time I reach my 800XLs for whatever reason...

 

Hope it makes some sense, now.

Edited September 6, 2019 by Faicuai

[flashjazzcat]

2 hours ago, Faicuai said:

However, if you wish to access SIDE as a smart-cart, or simply boot ANY other cart plugged in, you MUST first DISABLE "Hard Disk" or "PBI Bios" options on Ultimate BIOS menu

In the latest firmware (v.3.00 and beyond), the only thing which must be disabled in order to use the flash ROM on the SIDE cart as an external cartridge is the 'ATR swap button'. This will activate the 'SIDE cart ROM' setting on the front page which you then must turn on, as Roy points out. The OSS ROMs provided are intended to be used alongside the PBI HDD functionality, so would be of little use if one had to turn off the hard disk in order to use them.

 

Misread the second part of your post, so I've deleted the rest of my response since it was irrelevant.

Edited September 6, 2019 by flashjazzcat

[Jeffrey Worley]

2 hours ago, flashjazzcat said:

In the latest firmware (v.3.00 and beyond), the only thing which must be disabled in order to use the flash ROM on the SIDE cart as an external cartridge is the 'ATR swap button'. This will activate the 'SIDE cart ROM' setting on the front page which you then must turn on, as Roy points out. The OSS ROMs provided are intended to be used alongside the PBI HDD functionality, so would be of little use if one had to turn off the hard disk in order to use them.

 

Misread the second part of your post, so I've deleted the rest of my response since it was irrelevant.

Hoooray!  Thank you thank you thank you!

 

It has been MANY years since I wrote in Atari Basic and it is like riding a bike.  Really neat to get back on and find out I can still ride like a pro. :-)))

While I was still unsteady, I was digging for the bits in Waitcall I needed to tweak to get it to work with the Lantronix UDS1100, which is NOT an AT compatible 'modem' despite it's claims.  The emulation is PAPER THIN, five commands deep....  Anyway, I was wishing for the TRACE command so I could see what code was executing at what time and pinpoint the bits.

 

Last night I overwrote my waitcall with the gateway module,..  Duh.  All my mods went to wherever bits go.  I had to do it over, only took 45 minutes to re-discover the lines I needed to tweak, but I was still wishing for that Trace...  There's also the Fast command and a whole slew of other things.  Wow.  you are amazing man.  Truly The Flashjazzcat of Flashjazzcats.  The Flashjazzcat's Meow.

 

Thank you thank you thank you.

 

** TNM **

/s

Edited September 6, 2019 by Technoid Mutant

[flashjazzcat]

You may thank and show your support to @ebiguy for the OSS ROM conversions themselves. Much like Hias' high-speed SIO driver (which Matthias kindly allowed me to incorporate into the U1MB and Incognito firmware more or less verbatim but with a few augmentations and amendments), I treated Eric's patched ROMs as something of a 'black box' after realising I did not have the time to set about trying to make them myself.

 

My misunderstanding, BTW (in the interests of transparency), concerned the use of the SIDE SDX ROM. In my bleary state this morning I did not realise Faicuai was basically describing a 'stand alone' usage scenario (with all but the expanded memory of the U1MB disabled). Contention between U1MB SDX and SIDE SDX has hitherto been a source of confusion for many users, but usage was in this case correctly described. In all but the most obscure corner-cases, one should use the U1MB SDX ROM where it is available and not the SIDE SDX ROM. The latter should be reserved for stand alone ('U1MB-less') use. I suppose an exception could be when running an 800 OS on the U1MB: since the OS has no PBI support, the HDD would not work. One way to make it work would be via the SIDE.SYS driver, which is only included on the SIDE SDX ROM.

 

The most common source of consternation is when a SIDE user installs U1MB and then finds the system hangs on boot. The reason is that he left SDX enabled on both devices and has not suppressed the external cartridge's SDX by enabling the PBI HDD and turning on the ATR swap button (or manually disabling the cart with the button disabled, as is now possible). U1MB's SDX therefore boots, sees a cartridge (SIDE), initialises and runs it, and then two simultaneous instances of SDX come to a grinding halt. And even with the SIDE button in the upper position, unless 'ATR swap button' is enabled (or 'SIDE Cart ROM' disabled), the U1MB's SDX ROM will not boot at all; instead, the external loader will start up every time. This is because the loader disallows a disk boot, and SDX (as of recent revisions) will - instead of booting to the command line - immediately run a cart which disallows a disk boot. The reason the SIDE version of SDX doesn't do the exact thing 100 per cent of the time is that the SIDE version of SDX ignores the disk boot flag in the external cart ROM header, and boots to the command line regardless. Were it not for this change, it would be impossible to boot to SIDE's SDX command line, since the loader (which disallows a disk boot) is permanently attached as an 'external' cartridge.

 

Although recent versions of the U1MB firmware disable both SIDE ROMs (SDX and external cart) when 'SIDE Cart ROM' is disabled or when the ATR button is enabled, it's still safest to put the SIDE switch in the 'upper' (loader) position at all times when using the cartridge with U1MB. The OSS carts run persistently because the loader on the cartridge forces the appropriate base bank to be present before the OS really knows what's going on. Therefore the loader must be able to boot before any of the OSS ROMs are able to start.

 

Edited September 6, 2019 by flashjazzcat

[Marius]

Although I agree with FJC that other people also created wonderful stuff that makes his U1MB Bios + SIDE2 combination something fabulous, I think this is a good moment to say a big THANK YOU to FlashJazzCat for creating this stuff.

 

It is really adding something to the a8 experience, without losing the nostalgia feeling. U1MB + SIDE2 is fabulous (and indeed, with the OSS carts it is really complete). 

 

Thanks to FJC and all the other people involved (yes @ebiguy you thank you too!!) and yes @HiassofT thanks a lot too. 

 

Greetz

Marius

 

p.s. for those people who did not know that yet... on https://atari8.co.uk/ there is an orange DONATE button. Please do!

[Faicuai]

6 hours ago, flashjazzcat said:

In the latest firmware (v.3.00 and beyond), the only thing which must be disabled in order to use the flash ROM on the SIDE cart as an external cartridge is the 'ATR swap button'. This will activate the 'SIDE cart ROM' setting on the front page which you then must turn on, as Roy points out. The OSS ROMs provided are intended to be used alongside the PBI HDD functionality, so would be of little use if one had to turn off the hard disk in order to use them.

 

Misread the second part of your post, so I've deleted the rest of my response since it was irrelevant.

THANKS for the feedback! Quite useful, indeed!

 

I went back to my 800XL / Ultimates, and tried the above approach with my SIDE2 cart, loaded with OSS carts. Here's what I've found (consistently and repeatedly):

 

1. If SIDE2 cart is in "HDD" mode (lever-switch is "UP"), and booting BasicXE is needed, then the following options MUST be set on BIOS, accordingly:
   • DISABLE "ATR swap button"
   • ENABLE "SIDE Cart ROM"
   • Press SIDE2 button (top-left), once (if I previously booted as HD resource for Ultimate's built-in SDX or Loader).
2. If in addition to SIDE2, I would like ANY other cart to boot properly when inserted (without ever touching PBI-enable or Hard Disk options on main BIOS), the following settings-combo MUST always be set accordingly:
   • DISABLE "ATR swap button"
   • ENABLE "Cartridge reset"
   • ENABLE "SIDE Cart ROM" (to include all possible cart-booting scenarios).
3. With settings at #1 or #2, I was able to attach SIDE-hosted .ATR to "D1", and my own data .ATR to "D2", and booted BasicXE.
4. However, I can confirm that BasicXE does not work with its Extensions, on this setup, no matter what I do, even booting off SIO-attached .ATRs. In other words, and unless I am missing something else, BasicXE will not run with extensions, and will crash without them (after trying to run a program loaded from D2, for instance). If there is not another setting we are missing, we need to report this to ebiguy asap.

 

That's all I can report, for now.

Edited September 6, 2019 by Faicuai

[flashjazzcat]

That all looks correct. I take it you're using the cartridge reset BIOS plugin there. This is by no means essential for the use of other cartridges; I understand its purpose was to reset AtariMax carts back to bank #0 on system reset.

 

Of course it's rare for SIDE2 plus another cartridge to be simultaneously connected to the Atari, and simply accessing the SIDE IDE registers will immediately make - say - an AtariMax 8Mbit cart disappear off the bus. For that reason the most common and easy to remember method of using cartridges with an U1MB machine is to turn off the PBI hard disk entirely. This immediately shuts off all CPU access to the CCTL area (aside from that required by SDX, which you may disable separately), allowing all cartridges to function as normal.

 

I'll also reiterate that if the PBI HDD is disabled (for the purpose of using some other cartridge), you can leave the PBI BIOS enabled and use the high-speed SIO driver and "Z:" clock driver without interfering with cartridges at all. Only activating the HDD triggers CPU access to CCTL, and brings the SIDE cartridge ROM control settings into play.

Edited September 6, 2019 by flashjazzcat

[Jeffrey Worley]

Not to look a gift horse in the mouth....  I suppose there must be a compelling reason the rtc on the Side and in the U1MB are not directly compatible with the RTime8 cart, but would it be possible, given the combination of Side2/U1MB to make the SIde2 do this?  There's a whole lotta hardware in there to work with now that the U1MB is taking the load off.

 

I hate to piggieback an Rtime8 if I don't have to, but it is looking more like I will have to.  I'm running Carina II on Spartados 3.2g.  MOE doesn't like SDX and that isn't getting fixed by yours truly...  So I need RT8 or I have to keep entering the time and date manually on a system that has TWO battery-backed up real time clocks installed, or install a THIRD....

 

Wow man.  BXL works wonderfully.

 

Best,

 

Jeff

Edited September 6, 2019 by Technoid Mutant

[+DrVenkman]

13 minutes ago, Technoid Mutant said:

Not to look a gift horse in the mouth....  I suppose there must be a compelling reason the rtc on the Side and in the U1MB are not directly compatible with the RTime8 cart, but would it be possible, given the combination of Side2/U1MB to make the SIde2 do this?  There's a whole lotta hardware in there to work with now that the U1MB is taking the load off.

 

I hate to piggieback an Rtime8 if I don't have to, but it is looking more like I will have to.  I'm running Carina II on Spartados 3.2g.  MOE doesn't like SDX and that isn't getting fixed by yours truly...  So I need RT8 or I have to keep entering the time and date manually on a system that has TWO battery-backed up real time clocks installed, or install a THIRD....

 

Wow man.  BXL works wonderfully.

 

Best,

 

Jeff

Since you’re working with BASIC, is it possible to enable the Z: clock handler in the U1MB and call it from your program?

[Bikerbob]

18 minutes ago, Technoid Mutant said:

Not to look a gift horse in the mouth....  I suppose there must be a compelling reason the rtc on the Side and in the U1MB are not directly compatible with the RTime8 cart, but would it be possible, given the combination of Side2/U1MB to make the SIde2 do this?  There's a whole lotta hardware in there to work with now that the U1MB is taking the load off.

 

I hate to piggieback an Rtime8 if I don't have to, but it is looking more like I will have to.  I'm running Carina II on Spartados 3.2g.  MOE doesn't like SDX and that isn't getting fixed by yours truly...  So I need RT8 or I have to keep entering the time and date manually on a system that has TWO battery-backed up real time clocks installed, or install a THIRD....

 

Wow man.  BXL works wonderfully.

 

Best,

 

Jeff

Jeff you mean Basic XL? decided to go that route rather than XE? and are you running through the Side2 rom area? as per post #8 of this thread?

 

James

[Jeffrey Worley]

1 hour ago, Bikerbob said:

Jeff you mean Basic XL? decided to go that route rather than XE? and are you running through the Side2 rom area? as per post #8 of this thread?

 

James

Yep, BasicXL, on the Side2 cart, configured with the Sidecfg to load instead of the Side Loader program.  I like BXL because I know it works, and because the Fast command is in the cart, not on the extensions disk.  Carina is real fussy about memory, basically there isn't any to spare, so the extensions might cause problems.  I may try BXE later, but for now BXL is good.  Unless there's a compelling reason to run it?  The code is straight Sheperdson Basic, so any Atari basic compatible rom would theoretically work.  I've not tried Altirra Basic yet.  I gather it has some serious performance enhancements with regard to line-number lookup akin to the Fast command, but instead of a dedicated command, the basic looks from the bottom-up or something of the sort (pardon the pun).  Even in plain Atari Basic the performance of the system is a very pleasant thing to see.   If you didn't know it was running in Basic, you wouldn't deduce it from the speed of execution.

 

Best,

 

Jeff

Edited September 6, 2019 by Technoid Mutant

[Jeffrey Worley]

1 hour ago, DrVenkman said:

Since you’re working with BASIC, is it possible to enable the Z: clock handler in the U1MB and call it from your program?

I kinda burnt out on the rtc at about the time I gave up on SDX.  Once I got it running I started altering the modules to work on my lan hardware.  Now that I've got it there, I will try the zhandler that is included in rom.  IIRC, with the rom zhandler The tdline program does not reflect the correct date no matter what, so even if it works, it will be really distracting having the tdline reflect some bogus date and the zhandler reflecting another date.   And if I have to set the tdline by hand then I will have to get an RT8 and just go native, which kinda sux.  Three RTC's on the system.  A tdline that works with the Side2 would be a step in the right direction, would solve it, actually, if the zhandler works.  I will test tonight and advise.

 

Best,

 

Jeff

Edited September 6, 2019 by Technoid Mutant

[flashjazzcat]

2 hours ago, Technoid Mutant said:

Not to look a gift horse in the mouth....  I suppose there must be a compelling reason the rtc on the Side and in the U1MB are not directly compatible with the RTime8 cart, but would it be possible, given the combination of Side2/U1MB to make the SIde2 do this?

The only way SpartaDOS 3.x will work with the U1MB RTC is if someone writes a driver for it.

2 hours ago, Technoid Mutant said:

MOE doesn't like SDX and that isn't getting fixed by yours truly... 

What exactly symptoms are exhibited, exactly? The most common SDX issue is neglecting to use the 'X' command when starting a program which requires the cart to be disabled.

[Jeffrey Worley]

Just now, flashjazzcat said:

The only way SpartaDOS 3.x will work with the U1MB RTC is if someone writes a driver for it.

What exactly symptoms are exhibited, exactly? The most common SDX issue is neglecting to use the 'X' command when starting a program which requires the cart to be disabled.

"X Moe" loads the Moe, but when I exit to Basic, I get an Error 154 symbol not defined.  F  I've tried various combinations of zhand, tdline, moe, and the X command to load them or not and the problem remains the same.  Can't exit to Basic.  SDX barfs with an infinitely repeating error 154 on the screen and is unusable til cold start.  Funny thing is, on a system without the u1mb, running the Side driver, I can exit to Basic, but get screen garbage instead of text files when the system loads the waitcall.  It then bombs with an error 2 (out of memory).

 

So I went with the U1mb, but it displays the problems/errors in the first sentence above.  

[flashjazzcat]

27 minutes ago, Technoid Mutant said:

"X Moe" loads the Moe, but when I exit to Basic, I get an Error 154 symbol not defined. 

OK. This suggests that MOE itself has destroyed some SDX symbols in RAM. I'm curious to know how or why an executable loaded by 'X' could or would exit directly to BASIC. What is the purpose of this? Or do you mean exit to DOS?

 

If we look at the issue systematically, we might discover the reason for the apparent incompatibility, and possibly even a workaround for it. This might take a little investigation, but it would require somewhat less effort than writing an RTC driver for SpartaDOS 3.x.

[Marius]

I once wrote a tool, called Ultime.com ... it is like apetime. It downloads the time from Ultimate 1MB and put it in SpartaDos 3.x system clock. It was a rather fun project. But it is in no way a driver or a real time clock. It sets the time/date once and that's it (I put it in my startup.bat).

 

Later I adapted the waitcal0.cmd from BBS Pro! so it would download the time/date everytime the waitcal was executed (which was after every hour, and after every caller). That kept my time and date more accurate.

 

I will have to search for it, but I am pretty sure I can find at least the ultime.com ... source is most likely lost in space, as most of my sources

[_The Doctor__]

can the binary MOE be loaded from within basic?

or how about...

X /C program...

 

have you configured X not to use extended ram etc or to load above the standard extended 64k ?

 

exiting to basic? doesn't x dump memory and then likewise when re entering dump again, saving to mem.sav and or basic.sav when doing so...

 

Have you tried realdos by carden? or sparta 3.3x etc...

was there a driver for disk based DOS to access IDE of incog/pbi/side etc... I can't keep things straight sometimes, 2006/7/8 wasn't there IDE drivers being rolled out for the various widgets under disk based sparta's etc.

 

If not it would be a great idea to do so.

Edited September 6, 2019 by _The Doctor__

[flashjazzcat]

Is MOE the 'Modern Operating Environment'?

A binary would be kind of useful for troubleshooting here.

 

[_The Doctor__]

Yes that is MOE

[Jeffrey Worley]

1 hour ago, flashjazzcat said:

OK. This suggests that MOE itself has destroyed some SDX symbols in RAM. I'm curious to know how or why an executable loaded by 'X' could or would exit directly to BASIC. What is the purpose of this? Or do you mean exit to DOS?

 

If we look at the issue systematically, we might discover the reason for the apparent incompatibility, and possibly even a workaround for it. This might take a little investigation, but it would require somewhat less effort than writing an RTC driver for SpartaDOS 3.x.

Moe, the Modem Operating Environment is in PC parlance a 'Fossil driver'.  It takes io from the s: device and redirects it to the R: device and vice-versa.  It is a resident program.  In addition it hosts a slew of variables referenced by the Carina BBS (or any program), keeping the username and time online, what access the user has by sig, 80/40 column, screen breaks.....  A bunch of stuff.  Since atari basic doesn't have global variables, Moe just bumps memlo, reserves some ram space for variables, sets a standard for where those variables will be in memory according to a standard vector.  It also allows the modification of any of those variables in real-time, regardless of what the bbs is doing or being done to.  If a user is downloading, one can hit the option key a couple of times and an editable dli screen will descend.  The sysop can edit any of the user's attributes from there.  You can, for example, change the user's daily time limit or call time remaining or d/l ratio or #of dl's, or anything else, while he is actually uploading or downloading.  At the next block in the download, the basic module will update itself with the values input in the dli menu and act accordingly, including hanging up on the user for a u/l/d/l violation, time expired, whatever.  It is really a cool program.

 

So, the process of loading the bbs, presently, goes like this:

 

Basic on

tdline

x rverter (or just rverter)

x accel (screen accellerator for moe)

td on

x zhand

time

date

x ansi27 (a version of moe, I've tried all versions)

car (exit dos to Basic)

run "D:module>bootbbs"  (from this point the bbs is self-governing)

 

If you put this all in a startup.bat file, if you have a real-time clock you can omit the time and date, and the board will be power-failure-proof.

 

Attached is the bbs I'm running in its entirity, minus a couple of small mods I made to the basic code to make it work with the UDS1100 telnet 'modem'.  Those consist of nailing BDR variable inw waitcall module to 19200 instead of computing it from the Moe vectors, and changing line 2330 to:  "2330 I$="Connect":Return"  instead of fishing a bunch of stuff out of Moe that won't be right since it isn't a real modem.   Changing the computed value of BDR to simply "BDR=19200" is in line 2340 of Waitcall .  Both changes save a few bytes, actually.

 

Best,

 

Jeff

 

.

car_bbs.arc

Edited September 6, 2019 by Technoid Mutant

[ebiguy]

6 hours ago, Faicuai said:

THANKS for the feedback! Quite useful, indeed!

 

I went back to my 800XL / Ultimates, and tried the above approach with my SIDE2 cart, loaded with OSS carts. Here's what I've found (consistently and repeatedly):

 

1. If SIDE2 cart is in "HDD" mode (lever-switch is "UP"), and booting BasicXE is needed, then the following options MUST be set on BIOS, accordingly:
   • DISABLE "ATR swap button"
   • ENABLE "SIDE Cart ROM"
   • Press SIDE2 button (top-left), once (if I previously booted as HD resource for Ultimate's built-in SDX or Loader).
2. If in addition to SIDE2, I would like ANY other cart to boot properly when inserted (without ever touching PBI-enable or Hard Disk options on main BIOS), the following settings-combo MUST always be set accordingly:
   • DISABLE "ATR swap button"
   • ENABLE "Cartridge reset"
   • ENABLE "SIDE Cart ROM" (to include all possible cart-booting scenarios).
3. With settings at #1 or #2, I was able to attach SIDE-hosted .ATR to "D1", and my own data .ATR to "D2", and booted BasicXE.
4. However, I can confirm that BasicXE does not work with its Extensions, on this setup, no matter what I do, even booting off SIO-attached .ATRs. In other words, and unless I am missing something else, BasicXE will not run with extensions, and will crash without them (after trying to run a program loaded from D2, for instance). If there is not another setting we are missing, we need to report this to ebiguy asap.

 

That's all I can report, for now.

Hi

I am aware that there is a problem with the extension since it was reported several weeks ago.

To be honest, I did not know about the extension that's why I did not test it when patching OSS carts.

I have never used Basic XE and I have yet to get the extension disk.

I will have a look at this issue but give me some time as I am not full time on Atari stuff.

Meanwhile, if anybody has some hints about the diagnostic, it will help when I start working on the issue.

I guess that this kind of issue can be tracked with Altirra.

[_The Doctor__]

I'm not where I can check this at the moment but...muddled rambling of whatever to follow

without all of what you have listed being run autoexec...

with the latest versions of Sparta X...

what happens when the BXE cart is intalled and you type BASIC from the CP?

do you get Atari BASIC? Does it enter BXE?

I remember issues on a version of Sparta where you sometimes had to BASIC off before you could car sometimes (forget the exact details, not unlike why I forget why sometimes selecting cart above express when none is present helped with certain issues)

Edited September 6, 2019 by _The Doctor__

[Jeffrey Worley]

3 hours ago, Marius said:

I once wrote a tool, called Ultime.com ... it is like apetime. It downloads the time from Ultimate 1MB and put it in SpartaDos 3.x system clock. It was a rather fun project. But it is in no way a driver or a real time clock. It sets the time/date once and that's it (I put it in my startup.bat).

 

Later I adapted the waitcal0.cmd from BBS Pro! so it would download the time/date everytime the waitcal was executed (which was after every hour, and after every caller). That kept my time and date more accurate.

 

I will have to search for it, but I am pretty sure I can find at least the ultime.com ... source is most likely lost in space, as most of my sources

I was just about to report my findings.  The bbs DOES get the correct time and date from the Z: device provided by the U1MB bios.  The thing is, MOE gets ITS time and date from the tdline, by some mode or other and, the MOE derived time is the one used to stamp everything the board does, like message posts, logons, you name it.  The cool thing is that I'm pretty sure those locations are writable.  I just loaded the board without tdline installed and it runs, so perhaps I can modify the initial module (bootbbs) to poke the values gotten from Z: into the correct locations in MOE so that MOE will keep proper time from that point forth.  We'll see.  I'll probably be on jiffy time during board operation, with reboots/resets getting the time from the onboard clock the first time, at least that is what I envision and, what it.... OMGOD.  I want that utility.  Give me Ultime.com PLEASE.  That would solve my problem by setting the tdline just the once at startup.  Oh please find this utility.  Hmm.  Come to think of it, I might be able to write a little basic program that does the same thing.  Hmm.  Now I'm thinking of it.  Well, if you can find Ultime.com it will save me the effort.

 

Best,

 

Jeff

 

P.S.  Thanks to all for your kind concern.  I am touched.  Truly.

 

 

Edited September 6, 2019 by Technoid Mutant