Jump to content

Alfred

Members
  • Content Count

    822
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Alfred

  1. I spoke with Mike this afternoon. His life is in a bit of turmoil, he’s having to move on short (a week) notice among other things. He’s asked me to hold off on releasing anything until he gets settled in his new place, which should be in a couple of weeks. So we’ll see.
  2. Mike has responded without answering. Awaiting further responses.
  3. I had both, the first Black Box is connected to my programming system while the MIO handled the hard disks. I got another BB to take over as the mux host drive when I got the 210MB drive. My first 1MB MIO died early on and I personally delivered it to ICD in Illinois, met Harker and company. It got fixed and never crapped out again, but I rarely used it in the BB era.
  4. Probably only SpartaDos 2.3 and higher support the concept of "current working directory". MyDos 4.3 has a default directory but I don't believe it's the same, you can't CD around to change it. I don't know about the OSS DOS products, they have a CLI but that might be as far as they go.
  5. Many years ago I did something similar for a bbs door game in Rip Script. Not raycasting of course, just predrawn frames for each wall type, with predrawn lamps, doors etc. I believe we went with 5x5 so as to make it easier, two corridors on each side. Maybe something similar would work well here, like that other guys char-based mover. Players will forgive some graphics oddities if they are having a good time.
  6. I would hazard that most of the ICD stuff is lost, as is some of the OSS code. I don't think Mike has much, but who knows. I think anything prior to SDX is gone, with the exception of my copy of 3.5. SJC's RealDOS is based on 3.2, although I think he says it's from a disassembly. I have no knowledge of what went on there, if Lance or anybody was given a copy of the 3.2D source. As far as I know from Mike, 2.3 and 1.1 are lost, he did not get a copy from ICD. I had a copy Action! from ICD, Bob Wooley has coughed up Basic XL and Basic XE, although the version he has, 4.2, does not produce a functional cartridge/extensions combination. The MAC/65 code seems to be good.
  7. I don't know that I'm kidding, much. I mean I'm not going to release it next week, but when the time comes that I feel I have both feet in the grave, rather than just the one now, I would have no problem releasing the source code to the public. Sure Mike own the rights, but apparently he's not too hung up on granting permissions, or he'd have been all over DLT about them publishing their version. He's had 40 years to do something with any of the stuff he purchased from ICD, and actually I don't think he himself has a copy of anything anymore, although there's a miniscule chance I'm wrong on that point. Releasing the code doesn't deprive him of any income because there is none to be had, and DLT's version is far superior any way. Even if he did release an update, past experience with Mike has likely made a lot of people gunshy about sending him money for a product. You and I would do it, but that guy cx2k, not so much. Anyway, there's lots of time (hopefully, heh) to have some conversations about it. Or FJC can release his copy and the argument ends. To the other guy, why bother with GitHub. All the other source code is on Carsten's wiki, which seems good enough. Why not just keep posting stuff there, and people can copy it to whatever library manager they use.
  8. I'll text him and say since I never heard from him I'm going to release the code. Maybe that will get him off his ass.
  9. Well if that's all it is, someone could probably knock it out in Action! fairly easily.
  10. umm, no, it's not just set a breakpoint. I seem to recall there's at least three different ones with like five options each. There's what .ba and a couple others. I always have to look it up because I rarely use Altirra's debugger. The debugger in Altirra is amazingly capable; it is not very user friendly, especially if you don't use it all the time. DDT is a far easier interface to -learn-. I really don't get this total hostility you cross-assembler/cross-dev guys have towards developing on the machine itself. If you can't stand using a 40 column editor or god forbid the line editor in MAC/65, then how can you stand playing games in 4 colours in 160x192 or whatever mode E is ? Compared to Eve Online, Star Raiders is pathetic. So it takes MAC/65 45 seconds to assemble your code instead of two seconds in MADS. Really, your life is so short, that 43 seconds makes a difference? Jesus, I remember when Bob and I were working on BobTerm, and with DMA off it took just over six minutes for BobTerm to assemble from hard disk. I looked at MADS a couple of times, and I didn't see that it did anything better than MAC/65 except it was faster, which is a non-issue for me. Sure MADS is a nice tool, but it has a greater learning curve than MAC/65 without a doubt. Like someone mentioned earlier, all the Atari books are written with either ASM/ED or maybe MAC/65 in mind, not MADS, so if he's trying out examples from the various books, he'll be looking at a lot more frustration and less learning trying to do that with MADS than with ASM/ED. Sure he'll get it eventually, but it'll be a lot more work.
  11. Altirra's help file runs what, 10-20 pages ? Sure it has far more capabilities than DDT, far beyond what this guy needs. That doesn't make it easier to learn. I'm not suggesting that he clone BobTerm in MAC/65, but hands down, using MAC/65 on Altirra on a pc is going to let him learn assembly language at a more rapid pace than using MADS. It's a very simple environment, so he can focus on the code and not trying to remember the 25 options for setting a breakpoint in Altirra. No messing around transferring binaries to Altirra, it's just there. Once he knows the language, then sure, use WUDSN and read up on MADS. Sure, it's trivial for you; it's not trivial for him.
  12. I guess I'm not quite clear on what it is you want. I thought from your FB post, all the protocols would be written in C and run on the ESP32, so that in essence the NOS running on the Atari would be nothing more than a CLI interface that issues the commands to the ESP32 to Open File, Open Email, whatever the function is. Here though, it sounds like you're talking about protocols running on the Atari and talking to the protocol adapters on the ESP32. Which is it ?
  13. MADS has a much steeper learning curve than say MAC/65. Instead of spending time learning all the MADS features, and trying to learn the ones you actually need, it's simpler to use something like MAC/65 which is much easier to use, so the focus can be on learning assembly language and not on how to use MADS. DDT is also useful because you can immediately pop into memory and see your code in action.
  14. You mean like this: lda omode ; cmp #omwrt+omrea ; GODDAMN ATARI ASSHOLES ; beq rerr ; 2-20-86 and #omwrt bne posmid rerr lda #rnger jmp error posmid bit filpos+2 ; if filpos < 0 then error bmi rerr There's really very little bad language in the code, Mike must have had the patience of a saint.
  15. I guess I don't. I mean sure, it's fun maybe to read this once: $title(SpartaDOS - Version 3.5) ; 02-17-86 ; Version 3.2 completed and released. ; ; 12-09-87 ; Added Atari XF551 support for high speed and ; double sided operation. ; Source made compatible with the ICD XASM65 assembler. ; Version 3.5 completed (never released). ; 12-28-87 ; Found and fixed update mode bug in RSLW. ; Between 12-09-87 and now, SIO has been kludged for INDUS, ; XF551 and USD high speed mode. Status command kludge added ; because INDUS accepts high speed commands normally and will not ; respond. ; Moved CLI instruction in SIO. Caused lockup if errored out. ; 12-29-87 ; Updated source to use SEGLOAD functions just added to the assembler. ; Rewrote code in XERRORS. Much shorter now. ; 12-30-87 ; Finally have conditional assembly. Modifying source to handle ; diskbased and cartbased DOSes. Input flag is CARVER (1=cart ; based dos, 0=disk based) ; 12-31-87 ; Removed minibuffers and increased speed for the file and drive ; data table save/restore routines. ; 1-3-88 ; Extensive rewriting and organizing so that cart version and disk ; version use same modules except for the boot code blocks for ; each version. ; 1-?-88 ; Removed AINIT code and 256 byte buffer. Rewrote the READY routine ; and update boot sector routines to not need the 256 byte buffer. ; 2-5-88 ; Combining of MENU program to SpartaDOS CP. Involves redoing GENIO ; module and much of the filename processing and formatted directory ; routines. ; 2-15-88 ; MENU and Command Processor fully combined. Now have general error ; vector (GIO_ERROR) on GENIO. All print statements also in that ; module. The formatted directory listing has been generalized so ; that is useful from the MENU program. In the process, some of the ; AtariDOS formatted directory stuff is lost. Now working on Relocating ; Loader and Symbol Table. Next step is to get ADOS.SYS as an external ; module! revnum equ $35 ; SpartaDOS revision number $if carver srevnum equ 'R' ; sub version number... $else srevnum equ 'a' ; sub version number... $endif exbufs equ 16 ; Maximum possible number of buffers but after that, so what. If somebody really wants to know the history, go ask Gustafson, he's on LinkedIn.
  16. When I talked to Mike last October, I did ask him why he was hesitant to release the code. So he talked a lot, people who know Mike know how that goes, but essentially he still thinks there is something to be made with it, and if he releases the code then that door is closed. I think he's seriously mistaken, if only the for the fact that DLT have released a superior version and Mike is never going to catch up. There is no market for commercial Atari products large scale and Mike is truly kidding himself if he thinks that sort of thing is possible. All I will say about him is that he works as a tech at a very large ISP. Anyway, what's the point of releasing the source ? There is all kinds of source code on Carsten's wiki, and nobody has done anything with it in ten years. Jesus, there isn't even an 80 column editor for VBXE and that thing has been out since what, 2006 ? So the idea that anybody is going to study the Sparta code and do something useful with it is plainly wishful thinking, just like Mike. When somebody modifies Basic XE to use up to 1024K of banked memory, you let me know and then maybe I'll consider releasing the source to all the versions of SpartaDos in my possession.
  17. No, I've left a few messages on his voicemail and texted him and I've heard nothing in all this time.
  18. Maybe trying to learn assembly language with a complex assembler like MADS isn’t a great idea. Maybe try starting out simpler with Asm/Ed or MAC/65 and once you know the language you can always go back to MADS.
  19. Only one I’ve seen is the Orca assembler used in the Eyes & Lichty book for the Apple. Seems comparable to AMAC. Doesn’t matter, I’d say MAC/65 is simply the finest native assembler on the 8 bit. Lawrow really did an outstanding job.
  20. Anybody who has used the Assembler/Editor (or EASMD) and then discovered MAC/65 is never going to go back. Ever.
  21. .OPT OBJ required to assemble directly to memory
  22. Disk Wizard II is pretty much all I used back then. DiskRX now for SpartaDos.
  23. Well that's an interesting approach, develop the language first and then the projects later. I'm doing the opposite, as imo it would take so long to implement the language the projects might never get done. If your compiler generates code as good as the above for more complex contructs, my interest in it would definitely sharpen. Good 6502 code generators are rare.
  24. I have programmed in assembly language for different platforms for nearly 40 years now. On the Atari, assembler is my default because of the need for both decent performance and a small footprint. Most of the higher level languages are fairly inefficient. PL/65 wastes 1/3 to 1/2 of it's code to pushing or pulling things from the stack. CLSN Pascal is a veritable ocean of JSR calls to library calls and memory swapping code. Action! isn't too bad for say small projects, but it's handling of pointers and arrays internally is very slow. The other issue I have with high level languages like say Delphi which is what I mostly use on the PC these days, is that when you run into problems, you first have to determine if the bug is in your code, the compiler, or some third-party library. Assembly language doesn't have that problem, at least not on the Atari, where it's always your bug. Abstraction takes away from performance, and I don't see what advantage generic types and such bring to say developing a Robotron clone or a database program. I saw somewhere that Rebol was supposed to be good for implementing languages, so if could produce a modem version of say Action!, then from my point of view, perhaps it has its uses. It always kills me when some language maven gives an example of say a 1-line webserver implemented in their latest offering, as if the 5 million LOC in the backend to make it work just magically don't count. By all means, keep on with it. I think you might be disappointed in the crowdfunding response, but who knows, maybe people will pony up.
×
×
  • Create New...