Why More than 128K?

[BillC]

18 hours ago, Mazzspeed said:

My main workstation is a 2010 Dell T5500

Just curious, are you running the optional Red Hat Eneterprise Linux WS v.5, an upgraded version, or another distribution?

[Mazzspeed]

1 hour ago, BillC said:

Just curious, are you running the optional Red Hat Eneterprise Linux WS v.5, an upgraded version, or another distribution?

Running KDE Neon user edition. It's a fairly barebones distro released by the KDE devs themselves with a rolling release DE, but not as bleeding edge as the testing, unstable editions or developer editions.

 

It's based on Ubuntu 20.04LTS, but with some changes.

 

 

Edited February 4, 2021 by Mazzspeed

[Faicuai]

On 2/1/2021 at 5:36 PM, Mazzspeed said:

An example showing the benefits regarding a 16M REU with DMA controller on the Commodore 64.

 

Here's a video highlighting the differences in loading times comparing a virtual cycle accurate 1541 with 40k Ramboard expansion and JiffyDOS speed enhancements, vs DMA load directly into the memory of the C64 using the 1541 UII+. The difference in loading times is ~15 seconds vs about 2 seconds.

 

EDIT: Excuse my poor smartphone shaky and at times blurry filming. I'm using my left hand and recovering from surgery after I severed a tendon in my thumb...

 

 

Could not get back to this one, until now...

 

I wonder how a "ARC X FILENAME.EXT Dn:" command (with, say, SDX Toolkit .ARC master file) would run under this particular setup.

 

At the end of the day, somebody has to do the heavy lifting. It looks to me like, on the above context, the REU is not really a CPU-centric resource, but rather part of an external I/O server. I don't see the C64 main resources that much involved, other than the architecture itself, allowing DMA operations to take place (which is totally valid, of course).

 

However, a heavily transactional I/O cycle is what I would like to see how it works on this scenario, and how extended (or external RAM) is used to support it.

[Mazzspeed]

10 minutes ago, Faicuai said:

Could not get back to this one, until now...

 

I wonder how a "ARC X FILENAME.EXT Dn:" command (with, say, SDX Toolkit .ARC master file) would run under this particular setup.

 

At the end of the day, somebody has to do the heavy lifting. It looks to me like, on the above context, the REU is not really a CPU-centric resource, but rather part of an external I/O server. I don't see the C64 main resources that much involved, other than the architecture itself, allowing DMA operations to take place (which is totally valid, of course).

 

However, a heavily transactional I/O cycle is what I would like to see how it works on this scenario, and how extended (or external RAM) is used to support it.

Naturally it's impossible to run a SpartaDOS command on a C64, so it's difficult to compare directly. However you need to think of an REU on a C64 as chipram on an Amiga, essentially you have another DMA controller with 16MB of separate memory that the chipset can access directly as not to halt the 6510 during DMA access - Furthermore, this is how an REU has always worked on the C64, even the units released by Commodore themselves.

 

As I think I've stated previously, the capability of the REU is beginning to be used considerably considering NTSC games on the C64, the recent release of Ghosts 'N Goblins (PAL and NTSC) makes extensive use of the REU and is actually quite impressive.

 

NUVIE player shows off the raw IO throughput of the unit, streaming full 16 color video in high resolution mode no problem.

Edited February 4, 2021 by Mazzspeed

[Faicuai]

15 minutes ago, Mazzspeed said:

Naturally it's impossible to run a SpartaDOS command on a C64, so it's difficult to compare directly

Well, what I meant is any (typical) decompression tool on the C64, invoked from the DOS prompt, which will take a compressed file (with, say, executables and documents) and extract such content on another directory, within or outside the same HD drive.

 

In other words, a routine action like in any other DOS / workplace environment. That's a more systemic task, in nature. It involves quite a good deal of moving parts (even though it sounds simple).

 

(EDIT): ANOTHER example that comes to mind would be copying a 256KB or 512KB-long file, from HardDrive#1 CF, to HardDrive#2 CF. That is an interesting operation, especially with 512KB or more of extended RAM available. It would be interesting how it gets handled or implemented with DMA I/O. 

Edited February 4, 2021 by Faicuai

[TheNameOfTheGame]

On 1/31/2021 at 10:41 AM, flashjazzcat said:

It's a pre-emptively multitasking graphical OS capable of running sixteen concurrent processes. Not really a compelling argument for 1MB until it's finished and usable, but it's built into almost every U1MB board.

And it never seems to get going again since you have the work on the bioses.  I heard you had a financial interest in those though so that is understandable.  Gotta pay the bills and all.

 

With that in mind, maybe a Patreon or Kickstarter project could get you funds to resume work on the GOS.  A shame to see the project with so much promise languish.  It could literally transform our 8-bit machines and how we interact with them.

 

Could even have a Patreon going to finish development and then have the final product commercial also.

Edited February 5, 2021 by TheNameOfTheGame

[Mazzspeed]

1 hour ago, Faicuai said:

Well, what I meant is any (typical) decompression tool on the C64, invoked from the DOS prompt, which will take a compressed file (with, say, executables and documents) and extract such content on another directory, within or outside the same HD drive.

 

In other words, a routine action like in any other DOS / workplace environment. That's a more systemic task, in nature. It involves quite a good deal of moving parts (even though it sounds simple).

 

(EDIT): ANOTHER example that comes to mind would be copying a 256KB or 512KB-long file, from HardDrive#1 CF, to HardDrive#2 CF. That is an interesting operation, especially with 512KB or more of extended RAM available. It would be interesting how it gets handled or implemented with DMA I/O. 

The system is accessible via the DOS prompt, however for DMA speeds a modified kernel called the 'Hyperspeed kernel' is required that doesn't utilize the JiffyDOS/CMD-HD command set (as yet, still in development) - Due to the fact I have never, ever, used CBM DOS even in 1986 when I was a kid, I'm not 100% familiar with it's operation. Basically I can do what you're describing via JiffyDOS with CMD-HD extended commands no problem as that's what I use, but I have no idea how to do the same thing via the Hyperspeed kernel as it's not JiffyDOS compliant at this stage.

 

Kernel DMA loading support is still a very new thing, I was discussing the issues surrounding the lack of full JiffyDOS support with one of the developers the other day via FB chat, however I don't want to be pushy as it's their project and I feel respect is important. They tell me fixes are in development and knowing Gideon (the maker of the 1541 UII+ and Ultimate 64) I'm sure they are.

 

Another possibility when using the Ultimate 64 is the ability to configure the virtual 1541 using Dolphin DOS via a virtual parallel port as opposed to serial - In every way this is cycle accurate to the binary digit with a real Dolphin DOS setup and is very fast.

 

If it's DMA loads via the kernel you want to see, here's a video loading Ultima IV via the DOS/workplace environment. Using the menu like DOS built into the 1541 Ultimate II+ I can copy files between virtual 1541 drives using simple [CTRL] & [C] and [CTRL] & [V] (copy/paste) in a second or less (not shown in this video).

 

Sorry for the quality, just a quick and dirty smartphone video in between jobs.

 

 

Edited February 5, 2021 by Mazzspeed

[BillC]

2 hours ago, Mazzspeed said:

Running KDE Neon user edition. It's a fairly barebones distro released by the KDE devs themselves with a rolling release DE, but not as bleeding edge as the testing, unstable editions or developer editions.

I run a rolling release as well, PCLinuxOS with KDE5 DE, I first tried it soon after the 2007 version was released. I have also used Debian for an Open Media Vault home-built NAS.

[Mazzspeed]

4 minutes ago, BillC said:

I run a rolling release as well, PCLinuxOS with KDE5 DE, I first tried it soon after the 2007 version was released. I have also used Debian for an Open Media Vault home-built NAS.

I don't run rolling release distro's on my daily driver workstation anymore (bearing in mind that KDE Neon is only a rolling release DE), I have had issues with rolling release distro's in the past and avoid them now on my daily.

 

I also run an Ubuntu based server as a file server/TVheadend server for media/FTA DTV over the network using a Sony PlayTV dual DTV USB tuner.

[+Stephen]

1 hour ago, TheNameOfTheGame said:

And it never seems to get going again since you have the work on the bioses.  I heard you had a financial interest in those though so that is understandable.  Gotta pay the bills and all.

 

With that in mind, maybe a Patreon or Kickstarter project could get you funds to resume work on the GOS.  A shame to see the project with so much promise languish.  It could literally transform our 8-bit machines and how we interact with them.

 

Could even have a Patreon going to finish development and then have the final product commercial also.

It's incredibly rude to dictate how a hobbyist spends their FREE TIME writing FREE SOFTWARE.  How would you like it if some stranger came online and demanded your wife cook them dinner or wash their car because it would be convenient for them?

[TheNameOfTheGame]

 

5 minutes ago, Stephen said:

It's incredibly rude to dictate how a hobbyist spends their FREE TIME writing FREE SOFTWARE.  How would you like it if some stranger came online and demanded your wife cook them dinner or wash their car because it would be convenient for them?

 

Sorry, I know Jon and he is a great dude and am not trying to be rude.  I am simply suggesting some alternative revenue streams that might facilitate resuming development on GOS.  Everyone has to make a living and I understand that.  Calm down Stephen.  It's just Atari.  The world will keep spinning :).

[+Stephen]

10 minutes ago, TheNameOfTheGame said:

 

 

Sorry, I know Jon and he is a great dude and am not trying to be rude.  I am simply suggesting some alternative revenue streams that might facilitate resuming development on GOS.  Everyone has to make a living and I understand that.  Calm down Stephen.  It's just Atari.  The world will keep spinning :).

Also sorry - there's been a rash of posts on here (among other places) where a lot of demands seem to be being made.  Probably hit send before thinking about it.  All good (except for all the assholes at work cracking the whip down on me, demanding what I do, when I do it, and how fast).

[_The Doctor__]

more, faster, harder, better, now now now... do it, I thought this was done already. Did your get the memo? We're using the new cover sheet on the TPS reports... ah yeah

 

 

[TheNameOfTheGame]

24 minutes ago, Stephen said:

Also sorry - there's been a rash of posts on here (among other places) where a lot of demands seem to be being made.  Probably hit send before thinking about it.  All good (except for all the assholes at work cracking the whip down on me, demanding what I do, when I do it, and how fast).

All good.  I like you and am glad you are part of the Atari community.

[doctor_x]

23 hours ago, Mazzspeed said:

Running KDE Neon user edition. It's a fairly barebones distro released by the KDE devs themselves with a rolling release DE, but not as bleeding edge as the testing, unstable editions or developer editions.

 

It's based on Ubuntu 20.04LTS, but with some changes.

 

 

Could you please point me to that background? I would love to add it to my rotating backgrounds folder as well as my alexa show..

[Mazzspeed]

3 hours ago, doctor_x said:

Could you please point me to that background? I would love to add it to my rotating backgrounds folder as well as my alexa show..

PM sent my Friend.

[+ZuluGula]

@doctor_x, 

https://www.omgubuntu.co.uk/2020/09/kde-plasma-5-20-wallpaper

https://phabricator.kde.org/source/breeze/browse/Plasma%2F5.19/wallpapers/Next/contents/images/;00f3ea7b185bab2a4d0fe08355e89849e9aeb733

Edited February 6, 2021 by ZuluGula
added another source