Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Hm, but if the monitor doesn't do it's job, the device could compensate that. E.g. most of those mini retro consoles offer some decent scaling performances (even with CRT effects).
  2. Well, that's something i do not completely understand. Let's say we have an old 15" LCD and the resolution is a typical 1024x768. 1024-640 = 384 and 768-480 = 288 and those leftover pixels could be filled with the border colour. Thus we have a fixed 640x480 resolution and a left/right border of 192 pixels + top/bottom border of 144 pixels around it. Couldn't VERA handle that automatic "resolution filling/fitting"?
  3. For the IoT "example": Where did you learn that IoT needs to be fast (all the time)? BTW: Current hardware is easily fast enough for almost anything, no matter what language used. But of course there are always some exceptions :-).
  4. It doesn't matter at all what language it is. And i'm not a fanboy of Basic or C(#,++) or any other language. But: This is a forum for a computer with a mighty 64 kB of Ram. So 50 MB is a little bit more than that, isn't it? It's even more than the 640 kB we all know we'll ever need . And another hint: Please check your task-manager for any .net appplication. You'll find they use more RAM than the typical app. Although Java apps play in their very own league ...
  5. You are right, CLR alone is not very useable. The current version of the C#/.net runtime can be downloaded here: https://download.visualstudio.microsoft.com/download/pr/5e4695fb-da51-4fa8-a090-07a64480888c/65aa842670d2280b5d05b8a070a9f495/windowsdesktop-runtime-3.1.7-win-x64.exe --> It's more than 50 MB! .net core SDK (you want to develop, don't you :-)?) is more than 126 MB --> https://download.visualstudio.microsoft.com/download/pr/547f9f81-599a-4b58-9322-d1d158385df6/ebe3e02fd54c29487ac32409cb20d352/dotnet-sdk-3.1.401-win-x64.exe That's the definition of bloatware! You want even more proof Doigt? Just check your installed updates, you'll find loads of (almost monthly) .net patches. Which are huge, too. On the other hand: .net provides you with very much comfort and functionality. For that, you have to pay a price ...
  6. Yes, but still has a bloated runtime which has to be patched regularly ...
  7. That's a good thing (most of the time). It doesn't really matter if it's "object oriented" or "structural". Objects tend to become bloatware and structures need some discipline to maintain properly. And Java, excuse my french, is a pain in the ass: Bloated, slow, depends on a huge runtime (needs a paid licence for companies) and permanent patch-management ...
  8. What i suggested could be done without CPU or "external" DMA. Would be the same mechanism as initialising sprites, but for "blits". Strictly VERA internal. BTW: How does VERA handle HSCROLL and VSCROLL? Just changes a pointer or moves vMem content?
  9. Kinda (but much simpler).
  10. That's the basic idea, one tick is as fast as it gets. The other "Blitter" i had in mind was somehow crippled, because it had only access to slow (chip) ram. But with the X16, it's the other way round ... And there's DMA and then the other DMA. This one would be "internal". Could be triggered "immediate" or "IRQ-controlled" or something else, as long as it stays strictly VERA internal.
  11. Wouldn't it be nice/helpful to directly manipulate vMem (copy/move/clear) with the help of a small but fast custom VERA routine? Without burdening the CPU to much? One could even call it a blitter :-).
  • Create New...

Important Information

Please review our Terms of Use