Jump to content
IGNORED

U1MB, Incognito, SIDE2, SIDE3, 1088XEL/XLD Firmware 4.0 Released


Recommended Posts

On 8/18/2021 at 10:05 PM, Gryfon said:

 

“…issue seems to be related with side3 memory timing - no matter if there is ls08, als08, ahct08, f08 chip installed, doesn't matter what cpu is running, or antic chip

Wouldn't this be a possible cause for the issues I have with all 64GB Sandisk SD cards ?

Candle, what are the next steps to solve this issue ?

Link to comment
Share on other sites

On 7/16/2021 at 1:26 PM, flashjazzcat said:

I performed the test described above (booting straight into SDX after pulling the battery and putting it back, to completely clear the RTC), and the SIDE3CLK.SYS driver reports 'SIDE3 clock not present!'. This issue cannot be caused by the loader initialiasing the RTC, since the loader had at no point executed since the battery was reinserted.

 

I then went to the loader (which detected and reset the RTC without problems), set the date and time, and booted into SDX again. It still failed to detect the RTC. I will speak to Trub about this.

Currently, after replacing the battery, the driver should be forced to load with the /F option (SIDE3CLK.SYS /F). Then the time can be set with DATE and TIME commands.

This will be corrected in the next edition of SDX (along with other fixes).

 

  • Like 2
  • Thanks 2
Link to comment
Share on other sites

Big progress here. This is the SIDE3 loader (called with CAR here from the on-board SDX) silently auto-running a cartridge image straight after a cold power-up. The pathname of the cart is stored in an INI file on the FAT, writeable from the loader itself. I had to patch SDX to prevent it opening an SRAM window at $8000 (this causes the screen to go crazy when the DOS opens the extended RAM window after moving the display to $7C00), but once that's fixed, it's totally seamless. You'll be able to auto-mount ATRs as well (with U1MB) and even boot the machine directly to an XEX.

 

  • Like 10
  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...

I propose to make an in-depth video shortly about the FAT driver, but I just got wildcard file copying working in the loader's DOS and thought I would share. :)

 

 

This is FAT16, so the pause after 'DIR' is the driver trawling through a 65,000-entry FAT table to establish the free cluster count (which is thereafter stored in RAM for instant recall). The DOS and CLI are reasonably feature complete, supporting subdirectory creation/deletion, point/note, etc.

Edited by flashjazzcat
  • Like 13
Link to comment
Share on other sites

  • 3 weeks later...

Busy optimising the CIO FAT driver in order to squeeze in more stuff, but should be able to release a beta loader in a week or so. I'm still trying to find room for a raw directory mode so that the command processor can display a verbose directory, but at least we have a more or less SDX-compatible list of XIO commands.

 

chkdsk.thumb.png.ccbe47919fb20f87297a9cd7fcdb7752.png

 

Since the 'chkdsk' buffer has a different layout to that of SDX, I've put it on a different command (50), but most other Sparta XIO commands are supported, including get file size, set file pointer, set working directory, binary load, etc.

  • Like 8
Link to comment
Share on other sites

On 9/10/2021 at 4:58 AM, flashjazzcat said:

I propose to make an in-depth video shortly about the FAT driver, but I just got wildcard file copying working in the loader's DOS and thought I would share. :)

 

 

This is FAT16, so the pause after 'DIR' is the driver trawling through a 65,000-entry FAT table to establish the free cluster count (which is thereafter stored in RAM for instant recall). The DOS and CLI are reasonably feature complete, supporting subdirectory creation/deletion, point/note, etc.

Is this video unavailable for anyone else?

Link to comment
Share on other sites

@flashjazzcat  Well, just finished watching your latest video. Man you have been busy - amazing work! :D It's great to see in such detail what you have been doing for the past 2+months - thanks for sharing it with the community. (It's also quite interesting to see you do some amendments to the code on the fly also. :))

 

I won't pretend I understood the majority of the technical aspects and in particular the coding side of things. (In fact, having watched the video twice now (took a while for things to sink in:dunce:), I'm likley gonna brush up on a lot of stuff relating to the current SpartaDOS-X and general DOS related stuff. Been decades since I used it all and I've never been too adept at using command line interfaces - too spoilt with GUIs and not blessed with the best memory for remembering any command syntax). I've certainly not tapped into the potential of the SIDE3 and U1MB as it currently stands as yet.  Looks like it's about to get so much better.:) 

 

There are some really clever tricks and functions in the new DOS command line processor and also IHMO most encouragingly in the SIDE3 loader itself. (32MB ATR image creation in a little over a minute using a neat trick, and customisable ini files for pre-set/tagged CARs setup from a cold boot).

 

To also aim to have it function for 48k systems too will be most welcome for a lot of users. :thumbsup: (I think I understood this correctly?)

 

Incidentally for anyone who wants to hear a summary of the scope of things in the pipeline if you go into the video at around 1.17mins you can get the gist of the scope of things. (I highly recommend watching the whole vid as lot is demonstrated).

 

The idea we get raw read/write access to the FAT, can load directly from the loader as well as the command line, can create ATR images within the loader itself/and the new DOS command line, have access to the vast storage available and to potentially be able to read/write at high speed to it is very exciting.

 

Creating an new ATR image in the loader itself:

image.thumb.png.7a0c852fce8e47f7b3466ec59e8efa6a.png

 

Also as is mentioned in the video the idea of using it as a central hub for media is very intriging. We already have the excellent PDM player built into the loader. Talk of a possible video player to come. (Be interesting how that one works out).

 

Furthermoore for me by far the most exciting aspect of all of this - if I've understood correctly - is it gives scope to developers to create and run applications for a DOS environment, (ie not tied to a propriatory bootloader), and in particular games off the platform. There high score data, level progression, etc can be stored and from what I understand it allows chunks of game level data to be loaded into memory at high speed. The latter for me is something that really opens up the potential for future games on devices such as SIDE3 which utilise the capacity of cheap modern storage mediums, (SDcards), in this way. 

 

Also gonna be interesting to see what now occurs with FJC's other long running project GUI which will directly benefit from all the work done here with this FAT system.:D

 

Looking forward to flashing the beta as and when it's ready. :)

 

 

Edited by Beeblebrox
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

That's a good and accurate summary - thank you. Regarding overlays and performance in general: I left out the RWTEST segment of the video (it was getting out of hand), but RWTEST results on the FAT16 partition were ~60KB/s writes and ~69KB/s reading. Obviously the first run on a FAT16 volume (unless a prior operation has already established the free cluster count) will tend to be slow writing (since the FAT scan will be triggered when the test file is opened).

 

Filling VBXE VRAM and such should therefore present no problems.

 

Surprised no-one ID'd the bug in my code yet, especially given the number of imaginary issues which have been propagated over the years. :)

  • Like 2
  • Haha 1
Link to comment
Share on other sites

@flashjazzcat thanks :) Interesting re the RWTEST.  I'll watch the vid again re the bug. :grin:

 

Just whilst here I thought I'd mention something regarding the excellent inbuilt PDM player.

 

It's one of my fav features of the side loader. (I often play a few Stereo PDM tracks in the background these days).

 

Not wanting to sound remotely demanding( ;) ) but, what the hell ...may as well ask.... I've a few wishlist suggestions for future updates which I think would greately enhance this player.

 

So I am not sure if any is feasible - but... if ya don't ask ya don't get right?

 

- A cool graphic equalizer or colourful dot/wave/plasma effect to replace the white line one currently in place. Again the CPU might be too busy to have time to process this alongside playing the file. (The VLM on the Atari Jaguar was pretty cool).

- Onscreen display of the title or artist of the PDM file you are playing and if possible the duration, sample attributes, stereo/mono. (I don't know if the PDM files have the capacity to store header info containing this latter data?)

 

If at all possible:

- The ability to "tag" a PDM file with a number to create a mini playlist on PDM files in a single directory. (So in some respects much the same as when you are mounting more than one ATR). You then highlight the PDM file tagged as no1, play it and when it reaches the end the next track tagged in sequence plays. If you exit it at any point it returns you to the loader menu. If this were possible I'd imagine you could only tag within a particular directory. 

 

The ability to hook this up to my Oculus rift VR headset and control playback virtually using my hands......................  or perhaps simply by mind control ....:grin:;)

 

Actually whilst I type this I have my 800XL on and the Side Loader screen saver white text is up. Would be really cool is there was an alternative colourful screen saver as well, to really show off the A8. :)

 

Perhaps like Sine Wars demo (minus the ear bleeding noise heh heh):

 

or a cool equivalent of Colourspace:

 

Course I wouldn't want to be advocating anything that might inadvertently cause a seisure in anyone watching it! ;)

 

.......Not remotely demanding now .......am I? :ponder:

 

EDIT: I've quickly edited my post given I've only just now realised the loader's PDM player has a pause function and if that isn't great enough a skip forward and back function. How'd I miss that? Doh!:P

 

 

Edited by Beeblebrox
incorrect info corrected
Link to comment
Share on other sites

22 hours ago, flashjazzcat said:

BTW: I'll be quite impressed if anyone can spot the bug I introduced when I made changes to the FAT16 free cluster scanner.

Only thing that looks wrong is in:-

proc CountFreeFAT16Entries

        clc

        .byte $24

endp

 

Although $24 is a valid OP code it requires a parameter to work with :)

 

Probably totally wrong !!!

Link to comment
Share on other sites

1 hour ago, Beeblebrox said:

So I am not sure if any is feasible - but... if ya don't ask ya don't get right?

 

- A cool graphic equalizer or colourful dot/wave/plasma effect to replace the white line one currently in place. Again the CPU might be too busy to have time to process this alongside playing the file. (The VLM on the Atari Jaguar was pretty cool).

- Onscreen display of the title or artist of the PDM file you are playing and if possible the duration, sample attributes, stereo/mono. (I don't know if the PDM files have the capacity to store header info containing this latter data?)

 

If at all possible:

- The ability to "tag" a PDM file with a number to create a mini playlist on PDM files in a single directory. (So in some respects much the same as when you are mounting more than one ATR). You then highlight the PDM file tagged as no1, play it and when it reaches the end the next track tagged in sequence plays. If you exit it at any point it returns you to the loader menu. If this were possible I'd imagine you could only tag within a particular directory. 

Playlists are already on the to-do... um... list, but regarding the other stuff: you're right in thinking the CPU is pretty much flat-out, which is the reason I don't have static graphics on the screen (ANTIC DMA will then steal cycles from the CPU), and why the jog bar is only visible when you're actually pressing a key or when playback is paused.

 

Metadata is reasonable, even if only displayed prior to playback and/or when the jog facility is used, and I've already invited discussion of a suitable formalised file header design for PDM files and derivatives. As soon as that's done, I'll be happy to make the metadata available in the loader/player.

6 minutes ago, TGB1718 said:

Only thing that looks wrong is in:-

proc CountFreeFAT16Entries

        clc

        .byte $24

endp

 

Although $24 is a valid OP code it requires a parameter to work with :)

Good try, but no. BIT (ZP) is deliberately used here to skip the next instruction (SEC in this case); the skipped instruction serves as the operand to the BIT instruction. You can also do this with BIT (ABS) to skip the next two bytes, but you must be careful that the resulting bit test does not inadvertently interfere with read sensitive hardware registers, etc.

 

This code got stripped out, anyway, though, and the bug was in the newly written code. Clue: it concerns one of the index registers.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

@flashjazzcat 

"Metadata is reasonable, even if only displayed prior to playback and/or when the jog facility is used, and I've already invited discussion of a suitable formalised file header design for PDM files and derivatives. As soon as that's done, I'll be happy to make the metadata available in the loader/player."

 

Cool - yeah even if the details were made available just on the pause screen or when using the jog facility. TBH I'd be happy with the filename and total length of track. The progress of the track would of course be  a bonus as would any other metadata eventually made standard in the PDM header design.

 

Re playlist functionality  - I thought you might have something planned for the future. :thumbsup:  

 

The replacement for the SIDE 3 text screen saver was just a passing idea. :grin:

 

Getting more and more intrigued about gettin me hands on a beta......... no pressure heh heh! ;):P

 

thanks as ever.

Edited by Beeblebrox
Link to comment
Share on other sites

26 minutes ago, Beeblebrox said:

The replacement for the SIDE 3 text screen saver was just a passing idea.

I forgot to reference that: sorry. Yes, since there's abundant space, I would consider anything. Perhaps I can design a module API and people could then write their own screensavers.

 

  • Like 1
Link to comment
Share on other sites

2 minutes ago, flashjazzcat said:

I forgot to reference that: sorry. Yes, since there's abundant space, I would consider anything. Perhaps I can design a module API and people could then write their own screensavers.

 

No worries. Fantastic. Abundant space gooooooooooooood!  :grin: Great idea regarding the module API. People could feasibly have their own Rastaconverted (or other format) image files slideshow, or some great colourful effects. :D

 

 

Link to comment
Share on other sites

On 10/1/2021 at 6:18 PM, flashjazzcat said:

BTW: I'll be quite impressed if anyone can spot the bug I introduced when I made changes to the FAT16 free cluster scanner.

X was used to keep track of which half of the 512 byte sector is being addressed by BUFPTR, so it can't be used by SetFirstFreeCluster. Fix was to use a different method of checking we'd processed both halves of the sector.

  • Like 1
Link to comment
Share on other sites

@flashjazzcat  How's the world of Atari FAT and command lines coming on?  Bet plenty of coffee has been consumed? :) 

 

I've allocated this evening, (and probably the weekend), to more hardware tinkering with my latest aquisition - a broken 600XL. Managed to bring it back to life start of the week after hours of investigation and soldering, chip swapping, etc. Few issues to work out still.

 

Keep up the good work - it's so appreciated. ?

Edited by Beeblebrox
Link to comment
Share on other sites

18 minutes ago, Beeblebrox said:

How's the world of Atari FAT and command lines coming on?

I had some family matters to take care of this week, so coding time has been scant. But earlier in the week I realized I wanted access to the file pointer in raw directory mode (so that I can - for example - recursively parse the entire tree without needing umpteen file handles), and this prompted a complete redesign of said raw directory mode such that it works exactly like an open file channel. Once this works, I need to tighten up the file access modes (update, append, etc), and if there's any room left after that, I'll add a 'set volume label' function.

 

I know this will delay the beta a bit, but I'm enjoying working on the CIO driver so I'm just going with it. :)

23 minutes ago, Beeblebrox said:

I've allocated this evening, (and probably the weekend), to more hardware tinkering with my latest aquisition - a broken 600XL. Managed to bring it back to life start of the week after hours of investigation and soldering, chip swapping, etc.

That's great. Have fun with it!

24 minutes ago, Beeblebrox said:

Keep up the good work - it's so appreciated.

Thanks - I will. Be assured that if I'm quiet, it probably means I'm writing a lot of code. ;)

  • Like 4
Link to comment
Share on other sites

19 minutes ago, flashjazzcat said:

(so that I can - for example - recursively parse the entire tree without needing umpteen file handles)

Note that you probably should not do that with a recursive function. Your stack will overflow if it goes too deep. Best is to add tasks to a list for each recursion and handle that list. See old school Minix 2 and 3 ls -R by my old colleague kjb ;)

Edited by ivop
Link to comment
Share on other sites

33 minutes ago, ivop said:

Note that you probably should not do that with a recursive function. Your stack will overflow if it goes too deep. Best is to add tasks to a list for each recursion and handle that list.

I've written plenty of tree walkers (there's one in the loader's search function), and I usually push the file pointer to a stack (not the hardware stack) for each directory level. In fact the loader's tree walker works differently for 'reasons'; it builds a FIFO of directory cluster numbers as if encounters them at each level and then processes them when the current directory is finished processing (since the order of presentation is not important there). The important thing in this case is to be able to close the handle on the current directory half way through processing it, open child directories, and then return to the same position in the parent.

Edited by flashjazzcat
  • Like 2
Link to comment
Share on other sites

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...