All Activity

😲 I thought you could only use it once per level!

To be fair, I would guess that the girl is a Yardian raised by humans, however that sci-fi cliche goes. Also, WayForward is known for Shantae; of course they're gonna have a female protagonist and all that.

Best holiday reading 😁

Imagine a scenario where the bombs that you destroy in Missile Command are actually being launched by the Yars Race, and you would be given an option to play as either the Missile Command defender or the Yars attacker in an intense multiplayer mode, I think that would be great change of pace for a VCTR SCTR style game.

I will leave it up to you guys and the thread owner. Fragmentation should not be a problem with a competent search. ::shrugs::

After I found an original Atari 800XL PSU, I checked it and plugged it in. Its output is 5.1V, and on the board, it’s 4.99V and in Freddie 4,98V. So AGAIN after the comments of TZJB ... my thoughts turn to the awful soldered DRAM socket. The person who tampered with this board using incorrect crystals likely affected the socket as well. I removed the socket, I cleaned very carefully the pads and replaced it with a new one. I test the machine with the new empty socket and black screen again. But my hunch proved correct! After inserting a new KM4164 DRAM chip, the “Ready” message appeared with a distorted video, but with a “Ready” ! Yes, sirs! The board has come back to life! There are some more faulty DRAM chips that need to be replaced, and I hope the distortion of the screen will disappear. So, THANK YOU AGAIN, TZJB, FOR ALL YOUR HELP AND EFFORTS. I wish to help you in the future as well! This weekend, I am planning to socket all the DRAMs and identify the guilty component. This is looking promising. Atari 800XL PSU are normally somewhere between 5.1V and 5.3V so yours has a normal potential. Good call on the dodgy chip socket. You have made some good progress and now identified faulty DRAM which was similar to some of my issues with six KM4164 going faulty, so it's not just MT DRAM that can randomly expire, it seems Samsung can do it too. Regarding screen distortion, what display and method of connection are you using?

Updated ROM for "Max-it!". Some sound and animation improvements. Maxit.rom

Man, you're trying some real bangers there. More power to you. 🤣

Man this game literally came out of nowhere and has already grabbed my attention, beautiful anime/cyberpunk aesthetics ( guess I've been vindicated once again regarding which aesthetics/themes fit Atari's games and culture 😎), great metroidvania gameplay, the animations specifically the character movements is what they need to focus on improving right now, they just need a little more work put into them and they'll be just right, the main character is charismatic enough, looking forward to learning how exactly she's connect to the Yars Alien Race (I just hope she matures quickly and loses that cringy valley girl accent). Overall from what I've seen so far I think it has the potential to be an 8 out of 10 game if not even higher.

Prodatron (the SymbOS author) has been a regular participant in this thread and it was he who convinced me to abandon my mask-based window manager and replace it with a rectangle-based one similar to what he implemented in SymbOS. Indeed, it was he who convinced me to make the thing multi-tasking.

I guess it was SymbOS and the coder explained me the concept of those core routines and the layers on top. jac had some ideas on Atari ports. We talked about that gui window rewriting on layered windows while pac man clone was running in one of those. I also liked the abstract window gui layer as we had 4 Color display and monochrome display of the same app.

TikTok looking for a slice of users still using apps from the Meta empire: https://www.linkedin.com/news/story/tiktok-rolls-out-meta-challenger-5893417/

Relocatable code occupies no more memory than non-relocatable code once loaded from storage and fixed up in RAM, so the only real issue presented by the lack of an MMU seems to me to be the lack of memory protection (so random writes outside of the application's allocated RAM can be somewhat disruptive). The minimum RAM requirement is 128K, with (on that base configuration) 80KB available for resources and applications (four extended banks plus the main bank). That's ample for a handful of applications, resident resources, etc. In point of fact the system could probably run in 64K, although the limitations (16K for applications and resources) would severely impede usability. Although, since we now have a proliferation of mass storage devices which are as fast as RAM to RAM CPU block moves, it would be fairly trivial to cache an inactive process to disk if RAM was in contention. That's why the UI is one of the processes which runs entirely in banked ROM, consuming no RAM whatsoever. Applications, meanwhile, can implement a complex UI using minimal code (since they're just calling the OS instead of drawing everything themselves). Probably so, although all but a few of the most ardent coders will probably balk at the complexity of the window and dialogue descriptions and hope that someone also writes a resource editor to make application development less intimidating. Appreciated - thanks! You mean SymbOS? I had a cheeky idea the other week while making a video demoing 'Let's Emu' (Spectrum emulator for the 65C816). If we can emulate the Z80 at reasonable speed with Rapidus, would it not be feasible to emulate the CPC (with VBXE taking care of the emulated display)?

Innermost Secrets Of TI-99/4A by Randy Holcomb This was originally a series of articles in the Computer Shopper, and it was reprinted in booklet format, and I didn't see any good copy of it on the Internet, so decided to test out my Canon MF3010 scanner in seeing how well it makes a PDF, as I have a number of printed items, including some of my own source code only in paper format, so I wanted to do a test run to see how well I can scan a number of pages and do an OCR if possible on them. Looking forward to any experts out there on suggestions on what are good settings or software to use for the equipment I have which currently is just a Canon MF3010 and sadly can only manually do one page at time. In the meantime, enjoy this PDF of this booklet which is good beginner guide to using the VDP and file DSR for assembly language programmers out there that want to get started coding on the TI-99/4a computers. 🥰 TI99-InnermostSecrets.PDF

Moved to Completed: Impossible Mission (Port) by Gisberto Rondinella @Nop90 | Video Only (20240319) No Public Binary | Declared Complete: Apr 17, 2024 | Listing Updated: Apr 18, 2024

In the food fight game they already had the Yardian character and now they change him for a girl? It seems to me that Atari is wrong with the character design in this game. They had to continue with the characters already created in this new generation. Even so, I will wait to see gameplays of the game to decide whether or not to buy the game.

Moved to Completed: MazezaM (A8 Port) by budgames @tonma | Final Binary (20240416) | Declared Complete: Apr 16, 2024 | Listing Updated: Apr 18, 2024

Do you take the wide sync setting enabled with the latest tink4k firmware?

I will speak with @darryl1970 on how he would like to proceed on how and where to offer this as a digital rom later this year.

Added to WIP: Anthony's Big Adventure (32K) by Phillip Roberts @phillip_roberts | Video Only (20240415) No Public Binary | Listing Updated: Apr 18, 2024

Hey, Lex here. Lately I've been working on an HDMA sample streaming engine for the SNES. How it works is every frame a certain number of bytes of sample data is uploaded to an HDMA table in ram. The HDMA table is located 0x7E1000 in work ram. The "bytesPerFrame" variable controls how many bytes of sample data are uploaded to the HDMA table every frame. The HDMA table: Each entry in the HDMA table is 5 bytes. One line count byte + four bytes of sample data. However, the first entry in the HDMA table is a bit different from the following entries. In the first entry of the HDMA table the byte after the line count byte is 0xE0. When this entry is HDMA'd, 0xE0 will end up in the SPC700 register $F4. When the SPC700 program receives 0xE0, that tells it to begin receiving HDMA data. So when 0xE0 is detected the SPC700 program will start receiving HDMA data every scanline. After byte 0xE0, the 16-bit bufferStartingAddress will be stored in the first entry. The bufferStartingAddress is the address of the current audio buffer in the SPC700's ram that the sample data will be written to. Every entry after the first entry has a line count of 1 followed by four bytes of sample data. The actual sample data is begins at address 0x038000 in the rom. Every scanline this HDMA table will transfer four bytes of sample data to the audio registers $2140,$2141,$2142 and $2143. Here is the code for updating the HDMA table: arch 65816 ;Use the SNES CPU architecture. lorom !sampleAddress = $00 !sampleOffset = $0E ;The current offset in the current bank of sample data. !bytesPerFrame = $08 !bytesSent = $10 !currentScanline = $12 !sampleEndAddress = $20 ;The 24-bit address where the sample ends. !bufferStartingAddress = $3C !comparisonValue = $3E ;The value the bufferStartingAddress will be compared to. 144 x some number. !hdmaTable = $7E1000 macro byteToTable() ;This macro will transfer a byte to the HDMA table. LDA [!sampleAddress],y ;Load a value from the sample data. ;This will load a byte from the address stored at direct page $00+Y. ;$00 holds the sampleAddress. ;The sampleAddress is the 24-bit address of the sample. ;To get the final address of the current byte of sample data you do this: ;[$00]+Y STA !hdmaTable,x ;Store the byte. INX ;Increment the offset in the HDMA table. INY ;Increment the offset in the sample data's current bank. ;Y here represents the current offset in the sample's data. endmacro ORG $009000 update_HDMA_table: REP #$30 ;16-bit A, X and Y. LDX #$0002 ;Load 2 into X. ;X here will be used as the current offset in the HDMA table. ;$7E1002 is where the bufferStartingAddress will be stored. ;So $7E1000+X gives you the address $7E1002, the address where ;the bufferStartingAddress is stored in the first entry. LDA !bufferStartingAddress STA !hdmaTable,x ;Store the !bufferStartingAddress to data bytes 2 and 3 of the first entry. ;The !bufferStartingAddress is the address where the current sample buffer ;is in the SPC700's ram. LDY !sampleOffset ;Load the sample offset into Y. ;The !sampleOffset is the current offset in the current bank of the sample's data in the ROM. LDX #$0005 ;X will be used as the offset in the HDMA table. ;Set X to 5 so that we skip the first entry. ;Since each entry has a format of line_count+4 bytes each entry in the HDMA table is 5 bytes. ;So entry 1 starts at offset 5. STZ $2140 ;Clear $2140. update_loop: ;The loop that sends data from the sample to the HDMA table. SEP #$20 LDA #$01 ;Set the linecount byte for the current entry. ;The linecount will always be 1 for every entry that is not the ;first entry. ;So the 4 bytes of this entry will be HDMA'd and then one line will be skipped. STA !hdmaTable,x ;Store it to the HDMA table. INX ;Increment the offset in the HDMA table. %byteToTable() ;Send data byte 1 to the table. %byteToTable() ;Send data byte 2 to the HDMA table. label: %byteToTable() ;Send data byte 3 to the HDMA table. %byteToTable() ;Send data byte 4 to the HDMA table. check_sampleOffset: ;Check if the sample offset is greater than 0x7FFF ;If it is zero, the negative flag has been set. CPY #$8000 ;Compare Y(currentSampleOffset) to 0x8000; ;If Y is 0x8000 this means that we've transferred all the bytes ;in the current 32KB bank of the sample data to the HDMA table and need to increment ;the bank of the sampleAddress and reset the sampleOffset. BCC check_EndBank ;Have we transferred all the bytes in the current bank of the sample data? No? Then branch. reset_sampleOffset: LDY #$0000 ;Reset the sampleOffset to zero, so we start reading data from the start of the next 32KB bank. STY $0E INC $02 ;Increment the bank in the sample data, so the program starts reading the next 32KB of sample data. ;Basically we move to the next 32KB of sample data. check_EndBank: ;Check if the current bank of the sample is the ending bank. SEP #$20 LDA $02 ;Load the bank of the current sample address. CMP $22 ;Compare it to the bank where the sample ends. BNE check_GreaterThan ;Not equal? Go to update_bytesSent check_EndOffset: ;Compare the current sample offset to the end offset. REP #$20 TYA ;Transfer the sampleOffset to A. CLC ADC #$8000 ;Add 0x8000 CMP $20 BCS update_bytesSent sendStopCommand: ;Send the "stop" command to the SPC700 so it stops playing the sample. SEP #$20 LDA #$5E STA $2141 ;Write 0x5E to the SPC700 to let it know to stop the sample. LDA #$01 STA $28 ;Set the "sampleStop" boolean to true. jmp Transfer_Y ;Jump to the end of the code. endless_loop: jmp endless_loop check_GreaterThan: ;Check if the current sample address bank is greater than the endbank LDA $02 LDA $22 BCS sendStopCommand ;If the sample address bank is greater than the end bank branch. update_bytesSent: REP #$20 ;8-bit A. LDA !bytesSent CLC ADC #$0004 STA !bytesSent ;Add 4 since we sent 4 bytes of sample data to the HDMA table. CMP !bytesPerFrame ;Have we sent all of the bytes for the current frame? BNE update_loop ;No? Then loop. leave: REP #$20 ;16-bit A. ;A has to be 16-bit because we're going to add the 16-bit bytesPerFrame value ;to the 16-bit bufferStartingAddress. LDA !bufferStartingAddress CLC ADC !bytesPerFrame ;Add the bytesPerFrame to the bufferStartingAddress. STA !bufferStartingAddress CMP !comparisonValue ;Compare it to the comparison value. ;The comparison value is the offset where the final audio buffer ends ;in the SPC700's ram. BCC Transfer_Y resetting: LDA $80 ;Reset the bufferStartingAddress to the address of the first audio buffer in SPC700 ram. STA !bufferStartingAddress Transfer_Y: TYA ;Transfer the new sample offset to A. STA !sampleOffset STZ !bytesSent ;Reset the bytes sent. SEP #$20 LDA #$DF STA $2140 ;Store a value of 0xDF to $2140 to let the SPC700 know the SNES CPU is done updating the HDMA table. RTS After a certain number of bytes of sample data have been transferred to the HDMA table; the engine waits for VBlank and then transfers the HDMA table. Once the HDMA table is transferred the byte 0xC0 is transferred to the SPC700 to tell it that the PPU is currently in VBlank. After the HDMA table has been transferred, the program waits until scanline 0. After waiting until scanline 0; the SNES CPU will wait for the SPC700 code to send a byte of 0xFF. When the SPC700 code sends a byte of 0xFF, this means that it has finished receiving the HDMA data. SPC700 program code: On scanline 1, the first four bytes in the first entry of the HDMA table will be sent to the audio ports. The first byte that ends up in $F4 will be 0xE0. Byte 0xE0 tells the SPC700 to start receiving HDMA data every scanline. The 16-bit bufferStartingAddress will end up in registers $F5 and $F6. The 16-bit bufferStartingAddress stored after the 0xE0 byte gets stored into zero page addresses $08 and $09. Remember, the bufferStartingAddress tells the program the address of the current audio buffer. After the bufferStartingAddress has been received, the source directory entry for sample 0 will be updated. The sample start address and the sample loop address are the same as the bufferStartingAddress. The source directory is at SPC700 ram offset 0x1000. Once the source directory has been updated, there is some timed to code to wait 26 cycles. After the 26 cycles the program will be on scanline 2. After that, there is a timed loop for receiving the bytes for the current scanline's HDMA table entry and moving those bytes to the audio buffer. The loop for receiving bytes is always 65 cycles. There are approximately 65 SPC cycles every scanline. Byte-storing loop: So the first that happens in the loop is you transfer the first byte of HDMA data to A. Then you move A to the audio buffer in the SPC700's ram. Then you increment Y. Y is used as an offset in the audio buffer here. Then you do the same thing for the other 3 bytes for the current scanline's HDMA tavble entry. After transferring all of the bytes for the current scanline's HDMA table entry to the audio buffer, the loop checks if the negative flag has been set. Once Y overflows from 0xFF to 0x00 the negative flag will be set. If Y overflows, it will reset to zero and the low byte of the audioBufferAddress will be incremented. If Y didn't overflow, there is some timing code and if the scanlinesLeft value isn't zero, the code loops. Since the SPC700 registers are only 8-bit, when the high byte of the audioBufferAddress exceeds 0xFF; the low byte has to be increased by 1 and the high byte has to be reset. When the "scanlinesLeft" variable has a value of zero, that means all the HDMA bytes have been transferred to the audio buffer.After that the loop bit and end it of the last BRR will be set. The "scanlinesLeft" variable tells you how many scanlines are left in the HDMA table. The initial "scanlinesLeft" value is calculated by taking the bytesPerFrame value and dividing it by the "bytesPerScanline" variable. After all the HDMA bytes have been transferred, the loop and end bits are set for the last BRR block in the audio buffer.Here's the code for receiving HDMA data: arch SPC700 lorom ORG $028800 !scanlinesLeft = $0E !bytesPerScanline = $10 !bytesPerFrame = $D2 !sampleStopBool = $28 wait_DF: ;Wait for the SNES CPU to send a value of 0xDF. MOV A,$F4 CMP A,#$DF BNE wait_DF ;Once the SPC700 receives a value of 0xDF it knows that the SNES is finished updating the HDMA table. wait_5E: ;0x5E is a "stop" command. MOV A,$F5 CMP A,#$5E BNE scanlinesLeft stop: MOV !sampleStopBool,#$01 ;Set the "sampleStop" boolean to true. scanlinesLeft: PUSH X ;Save X for later. MOV X,#$04 MOVW YA,$D2 ;Divide the !bytesPerFrame by 4. DIV YA,X ;It is divided by 4 since the HDMA table will send 4 bytes every scanline. POP X INC A MOV !scanlinesLeft,A ;scanlinesLeft=!bytesPerFrame/4+1 wait_C0: ;Check if the PPU is in VBlank yet. MOV A,$F4 CMP A,#$C0 ;When 0xC0 arrives in $F4 that means that the PPU is in vblank. BNE wait_C0 wait_E0: ;Wait until the value 0xE0 is HDMA'd to $2140. ;When this happens the PPU is on scanline 0. MOV X,#$01 MOV A,$F4 CMP A,#$E0 BNE wait_E0 store_sample_offset: ;Store the initial offset where the sample will be in SPC ram. MOV $08,$F5 ;Store sample offset high byte. MOV $09,$F6 ;Store sample offset low byte. MOV A,$F5 MOV Y,$F6 PUSH A PUSH Y update_source_directory_hah: MOV $1000,A MOV $1001,Y MOV $1002,A MOV $1003,Y wait_26_cycles: ;Wait 26 cycles, after these 26 cycles the PPU will be on scanline 2. MOV Y,#$00 MOV Y,#$00 MOV Y,#$00 MOV Y,#$00 MOV Y,#$00 MOV X,#$01 MOV X,#$00 ;3 cycles INC Y MOV Y,#$00 ;4 cycles MOV Y,#$00 ;4 cycles MOV Y,#$00 ;4 cycles MOV Y,#$00 ;4 cycles MOV Y,#$00 ;4 cycles store_bytes: ;Store the HDMA'd bytes into SPC700 ram. MOV A,$F4 MOV ($08)+Y,A ;Move the first value. INC Y ;12 cycles MOV A,$F5 MOV ($08)+Y,A ;12 cycles INC Y ;Store the HDMA'd bytes into SPC700 ram. MOV A,$F6 MOV ($08)+Y,A ;Move the first value. INC Y ;12 cycles MOV A,$F7 MOV ($08)+Y,A INC Y ;12 cycles compare_Y: BNE wait_six_cycles ;4 cycles is_FF: INCW $09 ;6 cycles DBNZ !scanlinesLeft,store_bytes wait_six_cycles: MOV X,#$00 MOV X,#$00 MOV X,#$00 DBNZ !scanlinesLeft,store_bytes last_block: ;Calculate where the last block begins. POP A POP Y MOV $08,Y MOV $09,A ;Pull the offset from the stack. source_dir: MOVW YA,!bytesPerFrame ;Move the !bytesPerFrame to YA. CLRC ADDW YA,$08 ;bytesPerFrame+bufferStartingAddress = endOfBuffer. ;So to get the address where the the audio buffer ends you take the ;bytesPerFrame and add the bufferStartingAddress to it. MOVW !scanlinesLeft,YA ;Move the endOfBuffer position to $0A. SETC ;Set the carry flag. SBC A,#$09 ;Subtract 9. ;The last block starts 9 bytes before the address where the audio buffer ends. MOVW $80,YA check_sampleStop: MOV A,!sampleStopBool CMP A,#$01 BNE set_loop_bit set_end_bit: MOV Y,#$00 ;Clear Y. MOV A,($80)+Y ;Move the first byte of the last block to A. OR A,#%00000001 MOV ($80)+Y,A key_off_channels: MOV $F2,#$5C MOV $F3,#$FF loop: jmp loop set_loop_bit: MOV Y,#$00 ;Clear Y. MOV A,($80)+Y ;Move the first byte of the last block to A. OR A,#%00000011 MOV ($80)+Y,A send_FF: MOV $F4,#$FF ;0xFF is used to tell the SNES that we've fully transferred the HDMA'd bytes. wait_FE: ;Wait for the SNES CPU to send FE so we can continue. CMP $F4,#$FE BNE wait_FE MOV X,#$00 MOV $F4,#$00 ;Clear $2140. RET Going back to the SNES CPU code; the SNES CPU then receives a byte 0xFF, which tells it that the SPC700 is done receiving HDMA data. Then the SNES sends a byte of 0xFE to the SPC700 to let it know that it has received the 0xFF byte. Then the SNES program loops. Below I've included the source code and an example rom. Also warning, the code only works on NTSC consoles so far and won't work on PAL consoles. Using a custom song: To use a custom song, replace "sample.brr" with a 32KHZ BRR file. Then go into the command line, change to the location where you installed the source code and type "asar.exe main_streaming_code.asm HDMA_streaming_code.sfc". If you want to change the the address where the sample ends you will need to modify the sampleEndAddress which is stored at $20 in work ram. Also, the code doesn't support exLoRom currently, so your sample will need to be less than 4MB. You can use the code or modify the code however you like; however credit would be appreciated. Song credits: "Adventures in Adventureland" Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 http://creativecommons.org/licenses/by/3.0/ Here's a youtube video showcasing the engine: https://www.youtube.com/watch?v=lFJHG2BTIN8 HDMA_streaming_code.sfc streaming_source_code.zip

Hi, I have been looking for a socket 478 motherboard with a PC/PCI connector for a little while for a win98 build in the hope of getting good DOS sound compatibility with a YMF924 PCI sound card and I have found this one which has a promising yet unlabeled connector next to the PCI slots. Can anyone confirm that this is indeed a 5pin SB-link compatible header? The motherboard in question is a Matsonic MS9337C for which I have not been able to find any documentation...

So cool I had to pause work, hook up my 7800, load this up (Harmony) and play it. Really awesome.

Yes, but using Setltype (Set Language Type) is easier than doing the linking. As always (?) with the p-system, there are more to it than that. Let's recap how units work. Separate compilation One of the advantages of the unit concept in UCSD Pascal is that you can compile parts of your program separately. If the program is very large that's a necessity, since our little computer doesn't have memory enough to compile too large programs. By compiling a unit instead of a program, you create a support file for your program. The unit comtains an interface part which defines to the main program the data and procedures available and an implementation part which contains the code to execute. The user of a unit doesn't need to know how the procedures are implemented, only how to call them. You can even change the implementation without having to re-compile the programs using the unit, as long as the interface is the same. Compiling the unit This is as easy as compiling a program. Just run the compiler and it creates the code file for you. The basic structure of a unit is as below. unit example; interface type extype = record this, that: integer; end; procedure doexample(handle: extype); implementation procedure doexample; begin (* Code *) end; end. Compiling the program When a program uses a unit, it must know where to find the unit's code file. Easiest is if it's included in the *SYSTEM.LIBRARY file. Then it's all automatic. (Note that the * in the filename represents the system volume, i.e. the boot disk that was in #4: when starting the system. It's not part of the file name, but equivalent to passys: if the system disk is called passys. In such a case, *SYSTEM.LIBRARY is equivalent to PASSYS:SYSTEM.LIBRARY or #4:SYSTEM.LIBRARY, provided pasys is actually mounted in drive #4:.) In the case the unit is in a separate code file you need to tell the compiler where to find it. In the example below the first unit is in *SYSTEM.LIBRARY but the second is not. program unittest; uses support; (*$U develop:exfile.code *) example; Running the program When you run the program the same is true: If the unit is in *SYSTEM.LIBRARY everything works automatically. The build_env procedure in the operating system will locate the units referred to by your program and build the run-time environment records and vectors so the system can locate the files needed when they are needed. However, if the unit is still in a separate file, you need to tell the build_env where to locate it. This can be done by a text file listing the library files to search, just as @Vorticon showed above. In this example the content of the text file would simply be this: develop:exfile.code If you do store this in the text file called *USERLIB.TEXT (note that it must be on the system disk), then the program will find your unit. However, when you are designing your program you may not want to mess with a perhaps already existing *USERLIB.TEXT file. You can create a separate library reference file for your experiments. The content would still be like above, but you can store it in DEVELOP:EXLIBS.TEXT. But that's not where the run-time system will look by default. To make this work at runtime you have to use an execution option. You set it up by pressing X (for eXectue) at the top system level. But instead of entering a file name of a program to execute, you type in L=develop:exlibs.text. Now you've told the system you have a user-defined library reference file, so it can find it and through the information in it find your unit. You can list more than one unit in such a file, if you have your units spread all over the place.