Activity for David Ladd
-
David Ladd posted a comment on ticket #50
Thank you for looking into it. I found the issue and I figured I better report it. I use Linux Subsystem for Windows(Debian) and also MINGW(for building MAME) and also Raspberry Pi's for testing and building projects. I know someone wanted the current build of the HDBDOS WAV files related to DriveWire and the Deluxe RS232-Pak and Modem Pak. Which is how I found out it wasn't building.
-
Additional information: LWASM v4.21 OS: Raspberry Pi OS ARM64 OS: Debian 11 AMD64 OS: Ubuntu 18.04LTS AMD64 OS: Windows 11 AMD64 MINGW64 These are all the OS's I have currently tested under.
-
HDBDOS not building correctly
-
@tormod & @boisy, So as far as this goes I have tested the updated code and currently I have been using the os9 format command to create the HDD images for use on DriveWire. Now on the SDC I make sure to use a layout that is single sided to make sure that is comes as close to 128MB as I can get without switching to the next cluster size. os9 format -e -t29126 -ss -dd -n"NitrOS-9 EOU 6309" eou6309.vhd So far that setting creates a workable HDD image that works fine on the CoCoSDC. Though at this point...
-
I will have to verify that this is taken care of. I was hoping Allen would have responded if things were working as expected.
-
dwdos is not building fully and gnumake giving errors
-
Thank you Boisy for fixing this. It now seems to be building on all the platforms I have access too.
-
cocofuse not building on Ubuntu 32bit/64bit, Kali 32bit/64bit nor on Raspbian Linux
-
Thank you for pushing multiple commits to fix this. Now it is building as expected on Linux systems again. :)
-
cocofuse not building on Ubuntu 32bit/64bit, Kali 32bit/64bit nor on Raspbian Linux
-
Well that doesn't fix the problem as there are people who use cocofuse and thus you are effectively removing that support for all Linux, Unix, FreeBSD people except for those few of you who have macOS. Which is wrong.
-
cocofuse not building on ubuntu 32bit or 64bit nor on Raspbian Linux
-
dwdos is not building fully and gnumake giving errors
-
Added information about what was changed in last commit.
-
Updated format.asm to include the option for the enchanced 20 sector per track sector layout.
-
Updated stack copy routines for level2 krn module for 6809 provided by L. Curtis Boyle.
-
NOTE: Edition 4 now includes very slight optimizations, and two more drawing
-
RAMMER Edition #5 Revision 3 updates:
-
ASM Edition 11. Adds -o option (automatically overwrites object file), and is 7-13% faster (both on 6809 and 6309).
-
Updated thexs.asm to correct for 1MB and 2MB systems so that Thexder will run correctly.
-
Added in routine to clear out input buffer on the CoCo3FPGA's ESP8266-01 port and
-
Updated Level 1 VTIO and CoVDG for updates to do CoCoVGA.
-
Updated vtio.asm for some optimizations that can be shared between grfdrv.asm, covdg.asm.
-
Updated hdbdos/Makefile to build the hdbdw3bckwifi.rom and hdbdw3bckwifi.bin files for use
-
Updated hdbdos/Makefile and dwdos/Makefile to now create binaries for the
-
Updated HDBDOS dwread.asm and dwwrite.asm files for updated SY6551 routines so
-
Updated level2/coco3/modules/makefile to build Jim Brain's CoCoLINK RS232 Pak drivers for use with
-
Updated level1/coco1/modules/makefile to build Jim Brain's CoCoLINK DriveWire drivers. This
-
Modified the level1/coco1/makefile so that new disk images are created for DriveWire using the
-
Updated dwread.asm and dwwrite.asm so that the 6551 routines could have specially defined
-
Updated level2/coco3/makefile to now create DriveWire disk images using the
-
Updated rules.mak file so that DriveWire disk images for use in the DriveWire server are now
-
Fixed level1/coco1/bootfiles/makefile to include the bootfile_directmodempak_headless
-
Updated level1/coco1/bootfiles/makefile to create bootfiles and kernel track files that use the
-
Added new routine to dwread.asm and dwwrite.asm for using the SY6551 chips.
-
Updated makefile in level1/coco1/modules to create the boot and dwio modules for DriveWire
-
Updated dwio.asm to now check to make sure only install vport IRQ if reported version of DW is
-
Updated HDBDOS Makefile so that 3 new ROM sets will be made for DW3.
-
Updated dwread.asm and dwwrite.asm so that the base address for the SY6551 could be
-
Added DW routines for using the Deluxe RS232 Pak as the serial connection.
-
Updated level 1 CoVDG with a mini stack blast for the screen scroll.
-
Update to level1 CoVDG to save a few bytes of code.
-
Updated Level 1 GrfDrv & VTIO for performance and bug fixes.
-
Updated sources for syscall in basic09 packages to fix for incorrect offsets for 6309 because sources always expect 6809 offsets.
-
Release distro for ARM Linux flavors of HardFloat and SoftFloat
-
Made a few changes to level 1 VTIO for space and speed.
-
updated level1 term_vdg.asm to include upcoming CoCoVGA values.
-
Updated defs file cocovtio.d in preperation of CoVGA.
-
Ok so a quick update. L. Curtis Boyle and I have been working on VTIO for level1 to squash some of the issues. So far we now have the endless loop taken care of thus far. A updated VTIO.ASM for level1 has been submitted that will now properly load GrfDrv for level1 if it wasn't previously loaded. Some of the other issues that were described that are still lurking in GrfDrv have yet to be taken care of. So far it is just display codes $18 and $19 that aren't working as of yet.
-
Fixed level1 vtio.asm so that level1/GrfDrv properly gets loaded into memory
-
Ok after using MAME debugger to see if I could trace the problem down I believe the issue might be in the level1/modules/VTIO.ASM file: Closest thing I see is it is stuck in a loop that never ends. Here is the code that seems to be looping without end: AddrFind bita #$01 ; Done all shifts ? bne AddrDone addb #$2 ; increment addr offset ptr lsra bra AddrFind ; Test again So far I am not up to par to understand what is going on here yet for me to fix it, but I thought I would share what I have found...
-
Level 1 GrfDrv not getting loaded by VTIO or if GrfDrv is loaded system locks up calling GrfDrv related graphics
-
Added more detailed comments for syscall.asm to aid programmers
-
Merged in Boisy's changes for level1 covdg.asm for the CoCoVGA device from Branded & Ed.
-
KRNP3 speed optimizations (MoveBuf only copies 15 bytes,not 80,
-
Changed a puls PC to rts to save cycles
-
Did some more cycle optimizations in co42.asm
-
More co42.asm optimizations to save a few cycles on the Write.
-
Added some optimizations to co42.asm to save some space and cycles where possible.
-
Corrected ,pc should have been ,pcr in KRNP3.asm
-
Updated SDISK3 Driver makefile so it will have place holders for
-
Updated Disto Driver makefile so it will have place holders for
-
Updated IDE Driver makefile so it will have place holders for
-
Updated SDISK Driver makefile so it will have place holders for
-
Updated TCCC Driver makefile so it will have place holders for
-
Updated Drivers section makefile so it will process the dsk, dskclean
-
Updated MMC Driver makefile so it will have place holders for
-
Updated Burke&Burke Driver makefile so it will have place holders for
-
Updated s16550 Driver makefile so it will have place holders for
-
Pushing update to KRNP3 on behalf of Curtis Boyle.
-
Updated makefile for EmuDsk driver so that a disk image would be
-
Created makefile and defsfile for NoCan RAMMER module driver and descriptor
-
Submitting updates to GSHELL(Multi-View) to the repo from Curtis Boyle.
-
Updated os9format.c so that correct cluster size was created when
-
Updated os9gen.c for new option -l# which allows you to specify a custom LSN to start
-
DACIA Driver Missing
-
Robert, Thank you for letting me know. I will pass it along to Curtis. This is where I wish I understood the internal workings of OS-9 and how everything ties in together. :( Interesting trying to track down something that was intruduced 20+ years ago and wasn't found out till recently. (sigh)
-
Robert, You are right games shouldn't have done that back then as far as setting up that stuff themselves in OS-9, but obviously they did and OS-9 L2 must have had a machanic setup to handle that in case they did. Just in NitrOS-9 L2 must have at some point removed that machinic to handle that. :( Just speaking from a compatibility standpoint. :P Now as far as the game speed, yes it runs about 50 to 75% faster. I wrote a quick couple utilities that I put in the 3rdparty area in my area. I called...
-
Added a couple more utilities to my utils section as well as a README.md
-
Robert, Curtis and I have been doing some testing/playing around. He looked at the trace log from MAME's debugger and saw NitrOS-9 got stuck in some form of loop and just kept looping. So he looked at what disassembly files I sent him and saw something interesting. He saw that Cave was writing to FF03.Looks like it enables VSYNC PIA IRQ? Curtis had me use DED and did these steps. Used DED and skip to $D Then go to on screen to $0D You should see $B7FF03 Just for a test Curtis had me change that to...
-
Robert, Right and you are using VCC. Using VCC and NitrOS-9 L2 and CaveWalker does work, BUT here is the BUT....It does not work on real hardware. I have tested this as Barry brought this up to me. We have already proven that VCC does not emulate the CoCo3 completely right. So if you happen to have a real CoCo 3 to test on please try your test on real hardware.
-
Robert, Did you do your test using VCC? If you did it works fine on VCC, but does not work on real CoCo 3 or MAME.
-
Rorbert, also as a side note to this Biosphere & Interbank Incident are also able to run on OS-9 L2 too as well. I do not have a copy of Biosphere, but I was able to test Interbank Incident and it would not run under NitrOS-9 L2 either. Yet works fine on OS-9 L2. So yes there is a issue.
-
Robert, CaveWalker actually does run on OS-9 L2 without problem and even takes advantage of RGB/Composite selection. CaveWalker when played on Level 2 does produce some interesting intentional color shifting between stages. Very sycadelic if you ask me lol. Though down to known testing I have done though: CaveWalker DOES play on OS-9 L2 V2.00.00 CaveWalker does not play on NitrOS-9 L2 any version since public release on source forge. Thanks to Curtis Boyle who sent me a disk image from back when...
-
Support large files (disk images) on all architectures
-
Hmmmmm I will see about just doing the calculation in the while statement itself. I will post a updated diff when I am done testing the change. So far though the current routine I am using does seem to be doing the correct task. I attempted to create a 4GB HDD image with $FFFFFF sectors and it did come up with a cluster size of 64 which is the same thing I got from the NitrOS-9 format command. I have also been using dcheck with NitrOS-9 on a real CoCo via DriveWire to verify the volume. So far the...
-
Here is the diff file for the rules.mak changes I made.
-
After a while of Googling and searching found that on 32bit OS's the file access limit is 32bit and thus why I saw this issue. Found a way to correct this. By adding a -D_FILE_OFFSET_BITS=64 to CFLAGS line in rules.mak fixed this issue.
-
OS9 utility FORMAT category -e option failing to write past 2147483647 bytes
-
Yes the Dragon kernel track is set to 2. Which sadly I don't know enough about DragonDOS and how it loads up OS-9/NitrOS-9 yet. This is where I wish I had a Tano Dragon so I could experiance how this works on real hardware. So I could get a grasp for correct opperation. Also there isn't a check for 18 tracks. It is a check for minimum 18 sectors per track on disk images that are meant for use as real floppy disk images. As Disk Basic does require all 18 sectors to be present on the track. If they...
-
Hmmmmm I will see about just doing the calculation in the while statement itself. I will post a updated diff when I am done testing the change. So far though the current routine I am using does seem to be doing the correct task. I attempted to create a 4GB HDD image with $FFFFFF sectors and it did come up with a cluster size of 64 which is the same thing I got from the NitrOS-9 format command. I have also been using dcheck with NitrOS-9 on a real CoCo via DriveWire to verify the volume. So far the...
-
Yes the Dragon kernel track is set to 2. Which sadly I don't know enough about DragonDOS and how it loads up OS-9/NitrOS-9 yet. This is where I wish I had a Tano Dragon so I could experiance how this works on real hardware. So I could get a grasp for correct opperation. So far these new offset routines do work on a 2GB HDD image that I used on the CoCoSDC. So the default offset for 612 for HDD images works on a CoCo.
-
os9gen: Print unsigned integers correctly in summary
-
After some research and looking at the code, I believe I have a workable patch to the issue I found. Attached is a diff file that should take care of the floppy disk images and also this diff file includes a new option of allowing you to specify a starting LSN for the kernel track.
-
After some tinkering here is a possible solution I came up with for fixing the auto cluster size routine. I also included in this diff file a fix to a negative # value size summery when creating extreamly large HDD images.
-
OS9 utility GEN category will not write kernel track automatically to 19 or 20 sector based floppy disk images to correct start LSN offset.
-
OS9 utility FORMAT category auto cluster size causing floating point errors
-
OS9 utility GEN category add option to specify custom startLSN for kerneltrack
-
Interesting idea. Will be interested in where you take this.
-
Added some HD6309 optimizations to level1's covdg.asm file.
1 >
