mellis
-
Posts
339 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by mellis
-
-
Being a Spectre GCR user, I had already amassed a significant amount of Macintosh software and knowledge, so I purchased a Macintosh LC II.
As a 68000 programmer, I was very excited to have both the 68030 and the more sophisticated Mac OS (which was called System 7 at the time).
-
3 hours ago, Xebec said:
I just went to go play the awesome looking Cosmos Chronicles and noticed how dark my SC1224 was in this game.
I have definitely adjusted brightness and contrast up as much as the dials will go, but this game is still relatively dark. If I played in a dark room (i.e. wait for night outside), I think it'll be OK but in daylight (blinds on windows) the browns are pretty dark.
Are there any hidden knobs inside the SC1224 or anything else I can adjust or replace to brighten the screen? (I know CRTs are fairly dangerous if not taken carefully, and if it's drastic work required I'll take it to an experienced person).
I know my monitor is NOT the JVC style. Mfg Date is "Refurbished". Monitor (off) pics below for version.
(Option B is to pull out a 19" CRT and a scandoubler I have and build a wooden shelf to go over the Mega STe to protect it from the weight of the monitor
).
Your flyback transformer is getting ready to go. That was a pretty common issue on the Samsung and Goldstar (pictured) versions of the SC1224. Do not attempt to repair that unless you know how to discharge the mega voltage in the CRT without killing yourself.
-
On 6/6/2023 at 11:18 PM, x=usr(1536) said:
About a month ago, I did a complete reinstall of this laptop (I7 MBP, 2018) and 'upgraded' to Ventura. It's been... Fun.
For the life of me, I cannot get the CP210x drivers to work. They claim to install successfully, but the kernel extensions never actually load. Even trying to manually inject them silently fails. This is the case from both the Silicon Labs-provided installers and the homebrew silicon-labs-vcp-driver package.
Unfortunately, this is making it really obnoxious for me to update my FujiNets. Has anyone else run into this and, if so, how did you work around it short of my current solution of using a Windows VM to update? Nothing I've found online so far seems to apply.
It sounds to me like you are trying to install kernel extensions without disabling System Integrity Protection. Have a look at this link.
-
19 minutes ago, greggj said:
I'm trying to get back to writing for Atari 8 bit.
However, using the emulator on my laptop seems to be a bit silly. In this day and age I should be able to just write code on my laptop and run it on simulator.
It's possible to run Atari800MacX from CLI, to fire up a piece of code - or even run its generic - non macOS specific version (yay true opensource) atari800.
But I don't know what workflow folks use for making software under such conditions.
What compiler would you use?
Are there scripts out there already?
Please share.
Windows users seem to be using VSCode and Altirra , but the latter is very much a monolithic piece of software that cannot be easily made cross platform. Not to mention it's not developed in the open, even tho its source code is available. So it's clearly not the right avenue to pursue. And no, I am not going back to using windows, thanksverymuch
You might find that the SDL version of Atari800 will fit the bill, command-line-wise.
-
2
-
-
On 7/27/2023 at 6:43 PM, Harry Potter said:
]I have the code to read the strings into memory to conpile successfully but can't get it to run
This is C, so you are responsible for memory management.
Your Windows 11 box is crashing because Windows has memory protection, and you are likely writing to unallocated RAM. In doing so, it is doing you a favor; you now know you have a buffer problem.
If you are going to program in C, you will need to diagnose and fix this yourself. It is the only way for you to understand your mistake and avoid it in the future.
-
On 5/8/2023 at 6:23 PM, Jurie Horneman said:
Hey all. With help from friends from the ST community I have put most of the source code of Albion, the roleplaying game developed by Thalion Software back in 1991/1992, on GitHub.
This only includes the run-time, written in 68K assembly by me, not the editors, written in GFA Basic by Karsten Koeper.
It's reasonably well-documented, and includes lots of lyrics from Yes, my favorite band at the time, because that is a thing I did back then.I do love some "Yes". That would've been the Union album during that timeframe.
-
11 hours ago, Harry Potter said:
I believe myself to be a very good optimizer, even though I sometimes ask for help to optimize, but I find that the Atari 8-bit versions of my code are much larger than other versions, sometimes by more than 1k. I use my optimizations, including excluding unneeded code from the crt0.s files, my Cubbyhole optimization technique and excluding the system check code, and they are still larger than the other versions. What gives?
To wear the "good programmer" crown, one must understand the linker and the role it plays in producing an executable binary. There are many different ways to configure the linker in order to ensure that only the library/runtime code you really need is included in the resulting binary.
-
The M1 Macs are capable of running X86 binaries using their built-in Rosetta 2 emulator. It all works swimmingly for everything I've thrown at it (and I am a professional developer).
While I have not specifically tested the software you mention, I have not encountered anything which I ran on my Intel MacBook Pro that I can't run on my M1-based Mac with one exception: VMware Fusion. However, there is a solution for that also: Parallels. The latest Parallels will allow you to run ARM Windows, and that has its own X86 emulator for when you need to run X86 Windows binaries.
In short, I would not worry about upgrading. It will be fine.
-
2
-
-
On 4/12/2022 at 2:44 PM, Synthpopalooza said:
ok a question:
There is a tetris game that I remixed awhile back (The Wall by @itaych) and someone wanted a 5200 port of it. I have the source code (it's in XASM) so how does one go about porting this to 5200?
In light of the posts that preceded this one, I am not sure if you are joking. If you are, it's pretty funny.
In case you aren't joking, here are the steps (since this question seems to be quite popular):
1. Obtain a memory map showing where the 8-bit's custom chips appear.
2. Obtain a memory map showing where the 5200's custom chips appear (same chips, different memory locations).
3. Determine if the 8-bit program uses the OS, and if it does, rewrite those portions so that the program does not use the OS at all.
4. Determine where the 8-bit program access the controller inputs, and change those routines to scan the 5200's controllers.
5. Replace all of the 8-bit custom chip memory locations with 5200 memory locations.
6. Ensure that the program is only using RAM from 0 - $3FFF.
7. Ensure that the program instructions appear in the $4000-$BFFF range.
8. Get familiar with the assembler, linker, and debugger, and prepare to spend quality time with them.
And there you go! Only 8 steps, all of which require non-trivial programming and analysis skills.
-
3
-
-
On 3/30/2022 at 10:02 AM, Meadow Glen said:
I bought a xep80-ii. I know if bringing up an issue, it helps to have a video, so fyi, I don't.
But, for me, I went into Atari writer, which said it was patched for 80 columns, but it glitched within typing two sentences and although it was using 80 character font, it only used half the screen and was limited to 40 columns.
any others having this issue? any fixes?
Are you using AtariWriter or AtariWriter Plus 80? There is an important difference.
-
41 minutes ago, 8bit-Dude said:
Hey Guz,
Taking inspiration from https://playermissile.com/dli_tutorial/, I implemented vertical sprite multiplexing in 8bit-Unity last year.
However the performance is less than ideal in my new game "8bit-Strike". I still get excessive flicker when more than 2 multicolor sprites share the same DLIs.
I have seen some pretty impressive stuff on this forum (Like this: http://atariarea.krap.pl/24h/spritemania/STRSPLXR.COM)．So I wonder if anyone could point me in the direction of the "ultimate" sprite multiplexer in 2022? Something that does both horizontal and vertical multiplexing, with minimum use of CPU cycle....
Thanks in advance!
It sounds like you are looking for a general-purpose library (or routine) to handle the sprite multiplexing, but you are going to find that the only general-purpose implementations will lead to the flickering you have now. A flicker-free multiplexor will need to be designed around your specific game, with clever in-game constraints allowing you to reuse the same players/missiles on different scan lines.
-
1
-
-
Sure seems like you are observing an interrupt firing, and as a result, you are being carried into the OS.
-
I was paying attention when it happened (the 7800's release in the late 80s), and Pole Position II absolutely blew me away. Especially the track with the detailed and animated circus in the background.
Loved that game.
-
19 minutes ago, RSA said:
Do folks really re-invent the wheel for their own games? Or are implementations too optimized for specific needs to be reusable?
In short, "yes" and "yes".
The Atari's graphics capabilities are impressive, but employing them to their greatest effect is at odds with using a general-purpose library.
-
4
-
-
18 hours ago, JAC! said:
I have XCode installed, which contains the command line tools. Also from the
"From Mac OS X 10.9 onward, if Xcode is already installed in Mac OS X then Command Line Tools becomes installed as well"
It is only this specific lib (libc) which is no longer found since the last update...
Try using the environment variable:
LIBRARY_SEARCH_PATHS=/usr/lib
or possibly:
DYLD_LIBRARY_PATH=/usr/lib
after first confirming that /usr/lib/libc.dylib exists.
-
15 hours ago, JAC! said:
ld: library not found for -lc
An error occurred while linking
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Looks to me like the linker is looking for "libc", as indicated by the switch "-lc".
It is customary for *nix linkers to automatically drop the "lib" prefix when looking for libraries, so the "-l" switch is followed by "c", and prepending the "lib" prefix back gives you "libc".
Modern macOS versions do not ship with the command line compiler tools, but you can download and install them if you want. Check out this URL:
https://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/
-
Over the decades that I have been involved with Atari 8-bits, I've watched some folks look to higher level languages (like C or Pascal) for something faster than BASIC but easier to learn than 6502 assembly language. What ends up happening is that, outside of simple console I/O programs (which could be written on any computer) those languages do little to make programming our 8-bit Ataris any easier.
With such limited resources, programming a 64K computer requires a thorough understanding of its memory map and what that means in terms of the computer's underlying hardware. If you find these details too cumbersome, BASIC is truly the best, most approachable way to program these machines. When you get more comfortable with that, you can branch out into programming small, assembly language subroutines that can be used to speed up your BASIC program.
What I am reading in your threads is that you do not understand how the computer's memory map works, and therefore you struggle to properly configure the C linker. Unless you really understand the layout of your program in memory, you will continually struggle to make C do what you want on these machines. I assume you are attempting to program the 8-bit Atari because you want to take advantage of its graphics and sounds capabilities, but doing so will be very difficult in this language I believe you have chosen specifically because you think it will be easier (spoiler: it is not easier).
If Atari 8-bit sounds an graphics are what you seek, I recommend getting started in BASIC and then moving to assembly language.
-
12 hours ago, Fraggle said:
It would be fantastic if these 3 points could get implemented!
Indeed, that would be fantastic -- why don't you get to work on it? The source code is available here: https://github.com/lybrown/dis
-
1
-
1
-
-
3 minutes ago, TGB1718 said:
I'm trying to compile some code I wrote bitd using Lattice C V3.03.04, I'm getting a strange error on the
link phase:- Undefined Symbol MAIN, all other functions are fine, I get the same result regardless of which
file I try to compile/link, I know they have all compiled in the past.
So I just wrote the standard "Hello World" program and I still get the same error on the link phase.
The only think I can think is different now is I was originally working off floppy drives (possibly!! as I had a Syquest
removable drive at one point which unfortunately no longer works) and now I run off a hard drive.
It's not complaining about PATH's as I set these in the config file, just the MAIN procedure.
Normally you don't define MAIN, but I tried with and without defining it, same result.
Has anyone else seen/fixed this error.
In C, the prototype for main() is:
int main(int argc, char** argv);
Where argc is the number of command line arguments, and argv is a pointer to an array of char*, where each pointer points to a command line argument.
-
1 hour ago, danwinslow said:
You commented out your store of the printc jmp address in crt0.s, so now you have a JMP $0000 in there which is definitely going to be an issue. Looks like you were trying to jmp to the address in $E406 with a 1 added to it (?), which I guess is some kind of E: handler entry point, and the same thing for $E414. You don't have to do it like that, you could set printc up in C as a function pointer and set the address at that time, or just drop into ASM and jmp yourself, look at the options for the asm() function to see how to get symbol addresses/values into your asm statement. Your C program will start directly after crts0.s jsr to your main, so you can put any initialization you like there rather than messing with crt0.s itself.
Let me just say I think (if I understand) what your seem to be trying to do is probably not a great idea...if you are trying to jump around the CIO handlers by directly calling OS routines to save time, then (a) it's likely to cause problems, and (b) not sure you'll save all that much time. If you want REALLY fast screen writes then write your own code to do direct screen memory writes, or better yet wrap the conio.h calls in your functions, those are already pretty fast. Looks like you are moving a library from a commodore version, but Atari, generally speaking, you don't want to skip handlers and directly call OS functions, they were mostly all designed to be called by handlers or by the OS itself.
+1
I agree that bypassing the CIO handlers is bad idea: it will likely break on machines running upgrades that include alternate OSes.
-
1
-
-
2 hours ago, WizWor said:
I'll be 59 in April. I got my first Atari when I was 16 (2600) and my first Atari computer when I was 18. That was a 400 and it was $99.99 after a $50 rebate. My first computer and my first rebate. Great day. An 800XL, a 1050 disk drive, and a 1027 printer got me through college. Over the years, I have accumulated a lot of Atari hardware and software including a 1200XL, a few 800XLs, some 130XEs, and countless XEGS consoles. I have boxes of carts (no ET) and have burned some games onto a cart myself. I have an SD card reader for my Atari. I stored my Atari stuff when I bought a 80286 computer. When I had kids, I literally bought a hundred joysticks off ebay and we re-discovered Wizard of Wor, Bruce Lee, and many other great games. It's been a great ride.
But the reason I got a 2600 and all the Atari computers that followed was so that I could play very good imitations of the awesome games at the arcades.
In November I purchased a Legends Ultimate Arcade. It is awesome. It's a free standing, full size arcade machine. The controls are top notch. Audio and video are great. While it includes hundreds of great games, what is truly amazing is that you can play your own games on this machine. I have compiled a collection of my favorite Atari games to play, but I have also enjoyed playing the games that the Atari titles are based on. It truly takes me back to my youth.
I'm not ready to list my Atari hardware on Craig's List, but I honestly cannot see me playing games on an XEGS with a Wico Boss ever again.
When I was a kid, I loved that I could power on my Atari computer and lose myself in a great arcade game. Right now, I feel that way with the LUA.
Like I said, I'm not ready to liquidate my collection. I expect to have an Atari computer in my home until my last breath. I just won't be playing arcade games on it.
Have you seen these things? Are you curious? Have you bought one. What do you think?
Yes - and I prefer my Ataris.
-
26 minutes ago, Mark2008 said:
I've told this story before, but just sharing, in 2016, I ordered two ultimate Atari's. One was an 800XL and one was a 1200XL, both spec'd the same - u1mb, rapidus, vbxe.
It is kind of generally known now - but not then, that the u1mb and rapidus don't play well together.
So the 800xl was sold a long time ago, and I kept the 1200XL - it truly is marvelous. I wasn't truly happy with VBXE on either machine, at first, until 2020. I had been using a gonbes vga converter, but it had 'shake the last character' issue in 80-column mode. But then in 2020 I plugged a ST to SCART cable in - and it just worked, the original tech had wired up sound, and even though never tested with SCART, worked perfectly, and with a SCART to HDMI converter and a CCTV 1280 x 1024 19" monitor, the picture was perfection. Crystal clear, no character shake, no artifacts, no noise - the perfect screen, and that is important to me, I was happy about that.
Anyway, but I got a fujinet and one problem after another emerged, which turned out not to be the fujinet itself, but the fujinet does its software resets, that exposed to me, that my system is flakey on those resets, ack!
So, I thought about shipping it out to someone to repair. The issue with that, is it would've left me with no Atari, and I"m in the middle of development. So, I launched a plan to buy a 130XE with Rapidus/VBXE, but no u1mb. LIke the first time, I made 2 purchases from 2 different techs.
The 1200XL died yesterday and niether 130XE is a replacement. I'm without ultimate Atari after all. I know that in each case, they couldn't test and weren't aware of exaclty how I use my Atari. One of the machines works great on most software and flaked out like mad when used with 80-column terminal software. I even video'd it, but I decided not to share here, because it would be like a thing with the vendor. The other machine probably looked fine on the techs monitor, but fails to work with that crystal clear solution I found for the 1200xl and mentioned above, I mean literally unvieweable from some crazy ghosting issue....ugh, what bad luck.
The problem is, you cannot just send someone the machine to have it fixed. It might get fixed, it might not. It'll take 3 months and it'll be expensive. That's the reality if you lack mad soldering skillz....
Nevermind my recent experience, even in 2016, despite the genius skills of the techs, and undisputably perfect installs - the reality is rapidus and u1mb wasn't a valid combo and none of us even knew it.
4 attempts at this is enough, for me, I think.
I'll see if there is any solution to the 130xe display issue.... The Atari 1200xl, I don't know, I may sell it later, thats the likely answer, but anyway, I wasn't really doing an advertising thread, just a kind of grieving.
I can say that project didn't achieve its goals, but it did achieve one beautiful 1200xl with a perfect display. I surely prized that Atari....oh well ok, enough of me complaining today, I do have a native scart display arriving today or tomorrow. Who knows, maybe it'll work well with one of the remaining.
If you are really through with it, I will take that 1200XL off of your hands. Please don’t trash it.
-
12 hours ago, JGRAHAM2 said:
Have you seen a XEGS case top warp like this? Any suggestions on straightening it?
I had an ST do that. It was stored vertically in a box but outside of its original packaging in a hot attic.
I was able to correct the warping using modeling clay and an oven. I used clay to make a mold that supported the back side of the case, and then used more of the heavy clay and a carefully applied clamp to apply pressure to to top side to counteract the bowing. I then placed it in an oven set as low as it would go (around 200ish Fahrenheit). You need the plastic to heat up enough to soften a bit, but not enough that it melts or deforms. You will also need to put this on a hard surface to take it in and out of the oven. Less is more.
I’ve never done an XEGS, so this might or might not work for you. Be careful if you try it. I had nothing to lose, so I went for it.
-
1
-
1
-
-
43 minutes ago, JKK said:
Hi,
Quick question. The most popular 8-bit Atari computers have 64kB RAM (like 800XL, 65XE) or 128kB RAM (130XE). However something comes to my mind that there were models with higher memory provided by Atari, although when trying to search for it, I was not able to find that. Was it like that and if yes, could you give me the models numbers?
Btw, have ever Atari provided RAM extension modules, like Commodore? I don't mean extension modules of other companies (as many produced them) but genuine Atari modules? If yes, what were models numbers of these modules?
Thanks a lot for help
You might be thinking of Atari’s ST line, which was typically available with between 512KB and 4MB of RAM. There were some exotic sizes (like the 260ST or the high memory TT and Falcon configurations), but for most, 4MB was the upper bound.
-
1
-
). 
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
1450XLD, 1400XL, 1200XL, etc Badge Replacement Survey
in Atari 8-Bit Computers
Posted
Oh well - I would have ordered both a 1400XL and a 1450XLD badge just to have in the event I was able to acquire either machine sometime in the future.