Jump to content

kliepatsch

Members
  • Posts

    232
  • Joined

  • Last visited

  • Days Won

    8

kliepatsch last won the day on November 4

kliepatsch had the most liked content!

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

kliepatsch's Achievements

Enthusiast

Enthusiast (6/14)

Conversation Starter One Year In Dedicated Very Popular Rare Reacting Well

Recent Badges

164

Reputation

8

Community Answers

    I've never played Tetris this long before. Soothing music and sound and graphics. The second ingame music track is my favourite, the others are good, too. Enjoying the sound design
  1. I don't care so much for scores, but getting to hear the next sound track gives me some decent motivation to get some practice in this game! Sounds and looks soothing
  2. That's amusingly counter intuitive to me. I would have expected that the player "knows" at which speed it is running and advances the ticks accordingly. But it always thinks it's going 60 Hz, so you have to change the song speed instead. Is that variable you are talking about the choice between the different kinds of functions where one advances as many ticks as required, while the other one doesn't care and always advances one tick? If that's the case, I would probably not expose that, but infer it from the user parameters. Instead, I would let the player know at which frequency it's running so it can figure out by itself whether it's running at the same frequency as the song or not. Just my gut feeling. This approach would need more work. It would also mess up the nice "divide by 60" function ... That would be a shame.
  3. Yes, the compatibility of FM sound was broken between R38 and R39. So you likely listened to the PSG playing on its own. Here is one version of the song that plays under R41 in full quality TUNE.PRG
  4. Been working on a ZSM recorder lately. An X16-native ZSM has been recorded in the emulator with Concerto. See this post in the creative arts thread. Concerto-generated ZSM data in a typical song can be assumed to yield between 1 to 3 kB per second in 127 Hz tick rate (which is Concerto's native rate). This will be lossless and sound identical to Concerto itself playing it if played back at 127 Hz. It could theoretically be compressed to 60 Hz playback rate (lossy) and save about 50% of storage size.
  5. Here is a ZSM version of this piece, which can be played back on @ZeroByte's Calliope Player. It's in Concerto's native tick rate, 127 Hz, while Calliope runs at 60 Hz, so there is a compromise on audio quality, but still good I would say. Oh, and I am aware of the glitches on the second and later repetitions of the playback. My recording method was expecting all registers to be initialized with zero, which is not true anymore in the second repetition. X16FUNK.ZSM
  6. Yes, as far as I know. Petscii only knows uppercase letters, that's probably why.
  7. Do you know how tass64 is treating strings? Are they interpreted as petscii or ascii? Maybe you have to give the filename and commands in all-caps? If you are not sure, you could write down the petscii codes of the characters you want directly, instead of the string.
  8. You also need to call CHKIN. After that, calls to CHROUT will be written to your file. That, and what Stefan said: you need to add ",s,w" in the string after your file name. To me it is not entirely clear what all these commands are needed for, but I wanna try to summarize them. (Anyone, please correct me, I wanna learn!) First of all, you have to understand that this approach is compatible with how it was done on the C64 and similar machines. These machines had external disk drives, which had their own CPU and their own operating system (the CBM DOS). When you sent them the file name, they didn't use the file name right away, but they first interpreted the string that you sent over to the disk drive. Things like ",s,w". "s" stands for sequential file, "w" for write access ("r" for read). There's a good article on Wikipedia about this CBM DOS that ran on the disk drives. And the X16 Kernal somehow tries to emulate that behavior, although I am not entirely sure how much of it ... https://en.m.wikipedia.org/wiki/Commodore_DOS Then there is the concept of "logical files", which in my understanding is something like an I/O Port that you can choose to connect the Kernal to. If you have connected the Kernal to a logical file, you can read from it or write to it, using CHRIN/CHROUT. Here's my current understanding of the Kernal commands: SETLFS: tells the Kernal what a logical file is or where the I/O is redirected to. (Which logical file talsk to which device. No idea about what the secondary address does). SETNAM: Provides the Kernal with additional information it needs when opening a file on a disk drive. OPEN: Actually opens the file that is "currently" being looked at (defined by SETLFS). There can be several open logical files at the same time. CHKOUT: connects the Kernal's I/O to a certain logical file. This understanding does not explain all the behavior I have observed so far. So if anyone can correct me, please do
  9. What I have been wondering for ages now: what does the "secondary address" do when calling SETLFS? It must not be zero, that's pretty much all I know from experimentation
  10. Given that there are 857 calls to printf() and 849 calls to putchar(), and a call to printf() is at least 7 bytes each, probably 9 (LDA #Lo-address, LDX #Hi-address, (LDY #number-of-bytes-of-variadic-function), JSR 16-bit-address), and a call to putchar() is probably 5 bytes each, that alone accounts for at least 10 kBytes. Add string literals, stdlib functions, game logic and variables and you are probably going to hit these 40 kBytes. So I think there's no mistake in your compiling procedure or memory model or anything. It's just that the resulting executable really is too large to fit into "main" memory.
  11. Ok, given that most of the source code is printing things to the screen with stdlib calls, my __fastcall__ suggestion probably doesn't make much sense. So the executable size is largely defined by how much string literal data there is and how much a printf() call and a putchar() call will contribute to executable size. Given that the source file is 76 kByte, and a significant amount of that is literal strings, could it not be that it's about 10 kByte of literal string data alone, if not more? Maybe you are underestimating the size of the executable? That's just my guess ...
  12. The "main" memory area on the CX16 is something between 40 and 46 kBytes, don't remember the exact number. I have no experience in how # of lines of C code typically relate to executable size with CC65. What makes you assume that the result should be something like 10-15 kBytes? You could try denoting functions as __fastcall__, especially those with few parameters. Normally, with CC65, functions will use the emulated stack to pass parameters, but with the __fastcall__ convention, CPU registers will be used for the first 16 bits of the arguments. Maybe this also helps with executable size ... Just guessing.
  13. My code can be found here: https://github.com/biermanncarl/cx16-concerto/blob/master/concerto_synth/timbres.asm#L223 But it's messy and I haven't looked at it in a long time now. I would recommend looking at Stefan's X16edit code, where also proper error handling is done. (It was also my source of "inspiration": https://github.com/stefan-b-jakobsson/x16-edit/blob/master/file.inc
  14. On r38, I wasn't able to write files to the host filesystem with sequential access (if that is what writing individual bytes to an open stream means). But on r41 it worked for me. No sd images needed anymore
×
×
  • Create New...

Important Information

Please review our Terms of Use